LKML Archive on
help / color / mirror / Atom feed
From: Peter Zijlstra <>
To: Miklos Szeredi <>
Subject: Re: [patch 6/6] mm: bdi: allow setting a maximum for the bdi dirty limit
Date: Thu, 31 Jan 2008 11:17:47 +0100	[thread overview]
Message-ID: <1201774667.28547.286.camel@lappy> (raw)
In-Reply-To: <>

On Thu, 2008-01-31 at 10:46 +0100, Miklos Szeredi wrote:
> > On Tue, 29 Jan 2008 16:49:06 +0100
> > Miklos Szeredi <> 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?


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.

  reply	other threads:[~2008-01-31 10:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-29 15:49 [patch 0/6] mm: bdi: updates Miklos Szeredi
2008-01-29 15:49 ` [patch 1/6] mm: bdi: tweak task dirty penalty Miklos Szeredi
2008-01-31  0:13   ` Andrew Morton
2008-01-29 15:49 ` [patch 2/6] mm: bdi: export BDI attributes in sysfs Miklos Szeredi
2008-01-29 17:39   ` Greg KH
2008-01-31  0:28   ` Andrew Morton
2008-01-31  9:39     ` Miklos Szeredi
2008-01-31  9:54       ` Andrew Morton
2008-01-31 10:08         ` Peter Zijlstra
2008-02-29 11:26   ` Andrew Morton
2008-01-29 15:49 ` [patch 3/6] mm: bdi: expose the BDI object in sysfs for NFS Miklos Szeredi
2008-01-29 15:49 ` [patch 4/6] mm: bdi: expose the BDI object in sysfs for FUSE Miklos Szeredi
2008-01-29 15:49 ` [patch 5/6] mm: bdi: allow setting a minimum for the bdi dirty limit Miklos Szeredi
2008-01-29 15:49 ` [patch 6/6] mm: bdi: allow setting a maximum " Miklos Szeredi
2008-01-31  0:39   ` Andrew Morton
2008-01-31  9:46     ` Miklos Szeredi
2008-01-31 10:17       ` Peter Zijlstra [this message]
2008-01-29 17:06 ` [patch 0/6] mm: bdi: updates Peter Zijlstra
2008-01-29 18:32   ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1201774667.28547.286.camel@lappy \ \ \ \ \ \ \
    --subject='Re: [patch 6/6] mm: bdi: allow setting a maximum for the bdi dirty limit' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).