Messages in this thread | | | From | Benno Senoner <> | Subject | Re: [alsa-devel] Re: [patch] `cp /dev/zero /tmp' (patch against 2.2.9) | Date | Wed, 16 Jun 1999 20:28:47 +0200 |
| |
> Unfortunately it does completely the wrong thing if you have more than > one disk: it stalls all writes on all disks as soon as any one disk goes > into wait-on-read. That's not good. Not good at all. > > This is precisely the problem with optimising for one micro-benchmark. > > We really do need per-block-device IO scheduling, in some form or > another, to fix this once and for all. We already have the per-device > CURRENT queues, so some of the necessary infrastructure is in place > today (and the current mechanism does support devices specifying their > own queues to let them share queues sensibly). > > --Stephen
Stephen, do you think that a per-block-device IO scheduling will cure the 70-150ms stall of audio playing applications during heavy disk I/O ?
Just for curiousity , will it take much time to implement the per-device scheduling on Linux ? will future 2.3.x series have these features ?
Do you think that we could archieve similar low scheduling latencies as with microkerneled OSes (like BeOS) , or is this a design implementation of monolithic kernels ? From what I heard IRIX is able to handle RT scheuled processes with deadlines of 1ms even under high load, and IRIX is monolithic. (correct me if I'm wrong)
Therefore a 15-20ms max scheduling deadline (on modern PC hardware) should be realistic under Linux.
regards, Benno.
- 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/
| |