On Thu, 2008-01-31 at 10:46 +0100, Miklos Szeredi wrote: > > On Tue, 29 Jan 2008 16:49:06 +0100 > > Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > Add "max_ratio" to /sys/class/bdi. This indicates the maximum > > > percentage of the global dirty threshold allocated to this bdi. > > > > Maybe I'm having a stupid day, but I don't understand the semantics of this > > min and max at all. I've read the code, and I've read the comments (well, > > I've hunted for some) and I've read the docs. > > > > I really don't know how anyone could use this in its current state without > > doing a lot of code-reading and complex experimentation. All of which > > would be unneeded if this tunable was properly documented. > > > > So. Please provide adequate documentation for this tunable. I'd suggest > > that it be pitched at the level of a reasonably competent system operator. > > It should help them understand why the tunable exists, why they might > > choose to alter it, and what effects they can expect to see. Hopefully a > > reaonably competent kernel developer can then understand it too. > > OK. I think what's missing from some docs, is a high level > description of the per-bdi throttling algorithm, and how it affects > writeback. Because with info, I think the min and max ratios are > trivially understandable: they just override the result of the > algorithm, in case it would mean too high or too low threshold. > > Peter, could you write something about that? Sure. How about something like: Under normal circumstances each device is given a part of the total write-back cache that relates to its current avg writeout speed in relation to the other devices. min_ratio - allows one to assign a minimum portion of the write-back cache to a particular device. This is useful in situations where you might want to provide a minimum QoS. (One request for this feature came from flash based storage people who wanted to avoid writing out at all costs - they of course needed some pdflush hacks as well) max_ratio - allows one to assign a maximum portion of the dirty limit to a particular device. This is useful in situations where you want to avoid one device taking all or most of the write-back cache. Eg. an NFS mount that is prone to get stuck, or a FUSE mount which you don't trust to play fair. - 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
