LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: dean gaudet <dean@arctic.org>
Cc: Neil Brown <neilb@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines
Date: Thu, 11 Jan 2007 12:21:27 -0800	[thread overview]
Message-ID: <20070111122127.5bcc0b0f.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0701110245300.22043@twinlark.arctic.org>

On Thu, 11 Jan 2007 03:04:00 -0800 (PST)
dean gaudet <dean@arctic.org> wrote:

> On Tue, 9 Jan 2007, Neil Brown wrote:
> 
> > Imagine a machine with lots of memory - say 100Gig.
> 
> i've had these problems on machines as "small" as 8GiB.  the real problem 
> is that the kernel will let millions of potential (write) IO ops stack up 
> for a device which can handle only mere 100s of IOs per second.  (and i'm 
> not convinced it does the IOs in a sane order when it has millions to 
> choose from)
> 
> replacing the percentage based dirty_ratio / dirty_background_ratio with 
> sane kibibyte units is a good fix... but i'm not sure it's sufficient.
> 
> it seems like the "flow control" mechanism (i.e. dirty_ratio) should be on 
> a device basis...
> 
> try running doug ledford'd memtest.sh on an 8GiB box with a single disk, 
> let it go a few minutes then ^C and type "sync".  i've had to wait 10 
> minutes (2.6.18 with default vm settings).
> 
> it makes it hard to guarantee a box can shutdown quickly -- nasty for 
> setting up UPS on-battery timeouts for example.
> 

Increasing the request queue size should help there
(/sys/block/sda/queue/nr_requests).  Maybe 25% or more benefit with that
test, at a guess.

Probably initscripts should do that rather than leaving the kernel defaults
in place.  It's a bit tricky for the kernel to do because the decision
depends upon the number of disks in the system, as well as the amount of
memory.

Or perhaps the kernel should implement a system-wide limit on the number of
requests in flight.  While avoiding per-device starvation.  Tricky.

  reply	other threads:[~2007-01-11 20:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-09  8:57 Neil Brown
2007-01-09 10:10 ` Andrew Morton
2007-01-10  3:04   ` Neil Brown
2007-01-10  3:29   ` Neil Brown
2007-01-10  3:41     ` Andrew Morton
2007-01-11 11:04 ` dean gaudet
2007-01-11 20:21   ` Andrew Morton [this message]
2007-01-11 22:35     ` dean gaudet
2007-01-11 22:48       ` Andrew Morton
2007-03-07 10:23         ` Leroy van Logchem

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20070111122127.5bcc0b0f.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=dean@arctic.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --subject='Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).