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/