Theodore Tso wrote: > On Mon, Apr 27, 2009 at 03:47:42PM +0100, Jamie Lokier wrote: > > Personally, I'm interested in the following: > > > > - A process with RT I/O priority and RT CPU priority is reading > > a series of files from disk. It should be very reliable at this. > > > > - Other normal I/O priority and normal CPU priority processes are > > reading and writing the disk. > > > > I would like the first process to have a guaranteed minimum I/O > > performance: it should continuously make progress, even when it needs > > to read some file metadata which overlaps a page affected by the other > > processes. > > That's pretty easy. The much harder and much more interesting problem > is if the process with RT I/O and CPU priority is *writing* a series > of files to disk, and not just reading from disk. ... > I can't think of a filesystem where we would block a > read operation for long time just because someone was holding some > kind of filesytem-wide lock. A spinlock, maybe, but the only time it > makes sense to worry about boosting an I/O priority is if we're going > to be blocing a filesystem for milliseconds or more, and not just a > few tens of microseconds. ... > For the former, where a real-time read request gets blocked because > the read request for that block had already been submitted --- at a > lower priority --- that's something that should be solvable purely in > core block layer and in the I/O scheduler layer, I would expect. That's great to know, thanks. I will poke at the block layer and I/O scheduler then, see where it leads. Thanks, -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
