Messages in this thread | | | Subject | Re: [PATCH] deadline io scheduler | From | Daniel Pittman <> | Date | Fri, 27 Sep 2002 09:23:39 +1000 |
| |
On Thu, 26 Sep 2002, Jens Axboe wrote: > On Thu, Sep 26 2002, Daniel Pittman wrote: >> On Thu, 26 Sep 2002, Jens Axboe wrote: >> > On Wed, Sep 25 2002, Andrew Morton wrote: >> >> [...] >> >> > writes_starved. This controls how many times reads get preferred >> > over writes. The default is 2, which means that we can serve two >> > batches of reads over one write batch. A value of 4 would mean that >> > reads could skip ahead of writes 4 times. A value of 1 would give >> > you 1:1 read:write, ie no read preference. A silly value of 0 would >> > give you write preference, always. >> >> Actually, a value of zero doesn't sound completely silly to me, right >> now, since I have been doing a lot of thinking about video capture >> recently. >> >> How much is it going to hurt a filesystem like ext[23] if that value >> is set to zero while doing large streaming writes -- something like >> (almost) uncompressed video at ten to twenty meg a second, for >> gigabytes? > > You are going to stalll all reads indefinately :-)
Which has some potentially fatal consequences, really, if any of the capture code gets paged out before the streaming write starts, or if the filesystem needs to read a bitmap block or so, as Rik points out.
>> This is a situation where, for a dedicated machine, delaying reads >> almost forever is actually a valuable thing. At least, valuable until >> it stops the writes from being able to proceed. > > Well 0 should achieve that quite fine
Would you consider allowing something akin to 'writes_starved = -4' to allow writes to bypass reads only 4 times -- a preference for writes, but not forever?
That's going to express the bias I (think I) want for this case, but it's not going to be able to stall a read forever...
Daniel
-- It is quite humbling to realize that the storage occupied by the longest line from a typical Usenet posting is sufficient to provide a state space so vast that all the computation power in the world can not conquer it. -- Dave Wallace - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |