Messages in this thread |  | | From | (Linus Torvalds) | Subject | Re: 2.2.19pre3 and poor reponse to RT-scheduled processes? | Date | 30 Dec 2000 11:09:24 -0800 |
| |
In article <20001230191639.E9332@athlon.random>, Andrea Arcangeli <andrea@suse.de> wrote: >On Fri, Dec 29, 2000 at 04:54:23PM -0500, Rafal Boni wrote: >> Now my box behaves much more reasonably... I'll just have to beat harder >> on it and see what happens. > >Another thing: while writing to disk if you want low latency readers you can >do: > > elvtune -r 1 /dev/hd[abcd] > >The 1/2 seconds stalls you see could be just because of applications that waits >I/O synchronously while the elevator is reodering I/O requests (and even if the >elevator wouldn't reorder anything the new requests would go to the end of the >I/O queue so they would have some higher latency anyways).
That sounds like too long a stall to be due to elevator ordering except with some _really_ unlucky access patterns (or with slow disks).
There are other, equally likely, candidates for these kinds of stalls:
- filesystem locks. Especially the ext2 superblock lock. You can easily hit this one, as some ext2 functions actually do a lot of IO while holding the lock.
- synchronously waiting for bdflush with balance_dirty_buffers(). Especially mixed with the above.
A mixture of the two above will bascally stall the whole machine: almost any non-cached file access ends up waiting for the superblock lock and bdflush, and it can easily get quite unfair.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |