Messages in this thread | | | Date | Fri, 23 Jul 1999 05:58:52 -0600 | From | yodaiken@chelm ... | Subject | Re: real-time threaded IO with low latency (audio) |
| |
On Fri, Jul 23, 1999 at 02:20:53AM -0400, Paul Barton-Davis wrote: > it depends on what you mean by "any defined time". if a SCHED_FIFO > task is *not* running, and an interrupt occurs, then my sense of the > kernel code is that you are *guaranteed* that it will be scheduled to > run immediately. if the timer interrupts aren't frequent enough for > you, you need some other source of interrupts. for these purposes, > those of the soundcard itself work pretty well.
Try running while(1){ write(1,buf,1024*1024*8); }
while a SCHED_FIFO task is scheduled and see response time. Linux is designed to optimize average case response time. And it should be.
> This is what I mean by latency not being a problem. The difficulty > arises as soon the system is no longer quiescent: the kernel starts
Everything is easy when the system is not doing anything.
> grabbing locks, and the SCHED_FIFO thread gets shut out for several > msecs. This is bad for all of us. One reason why BeOS is a > "multimedia" OS is that they recognized that the old idea of what an > application "does" is wrong (i.e. many "modern" applications do 98% of > their I/O to the video card and/or a soundcard).Lock-taking to protect > what would have historically been universal (or at least heavily worn) > paths through the kernel is now often just an impediment to timely > execution. Yes, the scheduler still needs some global locks, as does > the VM/MM system, but very else little else should be guarded in the > way it is now. Everyone on l-k knows this - its just a big task to > change it.
Linux is not losing time locking/unlocking, it loses response time by not preempting tasks in kernel mode. But preempting tasks in kernel mode would be a terrible design choice for a general purpose OS and it a terrible pain in the ass to maintain.
BTW: I have never seen any serious performance numbers on BEOS. Do you have a source?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |