mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Neil Brown <neilb@suse.de>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: RFC - how to balance Dirty+Writeback in the face of slow writeback.
Date: Fri, 18 Aug 2006 08:17:17 +1000	[thread overview]
Message-ID: <20060817221717.GV51703024@melbourne.sgi.com> (raw)
In-Reply-To: <17635.60378.733953.956807@cse.unsw.edu.au>

On Thu, Aug 17, 2006 at 02:08:58PM +1000, Neil Brown wrote:
> On Wednesday August 16, dgc@sgi.com wrote:
> > 
> > IMO, if you've got slow writeback, you should be reducing the amount
> > of dirty memory you allow in the machine so that you don't tie up
> > large amounts of memory that takes a long time to clean. Throttle earlier
> > and you avoid this problem entirely.
> 
> I completely agree that 'throttle earlier' is important.  I just not
> completely sure what should be throttled when.
> 
> I think I could argue that pages in 'Writeback' are really still
> dirty.  The difference is really just an implementation issue.

No argument here - I think you're right, Neil.

> So when the dirty_ratio is set to 40%, that should apply to all
> 'dirty' pages, which means both that flagged as 'Dirty' and those
> flagged as 'Writeback'.

Don't forget NFS client unstable pages.

FWIW, with writeback not being accounted as dirty, there is a window
in the NFS client where a page during writeback is not dirty or
unstable and hence not visible to the throttle. Hence if we have
lots of outstanding async writes to NFS servers, or their I/O
completion is held off, the throttle won't activate where is should
and potentially let too many pages get dirtied.

This may not be a major problem with the traditional small write
sizes, but with 1MB I/Os this could be a fairly large number of
pages that are unaccounted for a short period of time.

> So I think you need to throttle when Dirty+Writeback hits dirty_ratio
> (which we don't quite get right at the moment).  But the trick is to
> throttle gently and fairly, rather than having a hard wall so that any
> one who hits it just stops.

I disagree with the "throttle gently" bit there. If a process is
writing faster than the underlying storage can write, then you have
to stop the process in it's tracks while the storage catches up.
Especially if other processes are writing tothe same device. You
may as well just hit it with a big hammer becauses it's simple and
pretty effective.

Besides, it is difficult to be gentle when you can dirty memory at
least an order of magnitude faster than you can clean it.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  parent reply	other threads:[~2006-08-17 22:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-14 23:40 Neil Brown
2006-08-15  8:06 ` Andrew Morton
2006-08-15 23:00   ` David Chinner
2006-08-17  4:08     ` Neil Brown
2006-08-17  6:14       ` Andrew Morton
2006-08-17 12:36         ` Trond Myklebust
2006-08-17 15:14           ` Andrew Morton
2006-08-17 16:22             ` Trond Myklebust
2006-08-18  5:49               ` Andrew Morton
2006-08-18 10:43                 ` Nikita Danilov
2006-08-18  0:11         ` David Chinner
2006-08-18  6:29           ` Andrew Morton
2006-08-18  7:03             ` Jens Axboe
2006-08-18  7:11               ` Andrew Morton
2006-08-18 18:57               ` Andi Kleen
2006-08-21  0:35                 ` Neil Brown
2006-08-21  3:15                   ` David Chinner
2006-08-21  7:24                     ` Neil Brown
2006-08-21 13:51                       ` Jens Axboe
2006-08-25  4:36                         ` Neil Brown
2006-08-25  6:37                           ` Jens Axboe
2006-08-28  1:28                             ` David Chinner
2006-08-25 13:16                           ` Trond Myklebust
2006-08-27  8:21                             ` Neil Brown
2006-08-21 14:28                       ` David Chinner
2006-08-25  5:24                         ` Neil Brown
2006-08-28  1:55                           ` David Chinner
2006-08-21  7:47                     ` Andi Kleen
2006-08-18  7:07             ` Neil Brown
2006-08-17 22:17       ` David Chinner [this message]
2006-08-17  3:59   ` Neil Brown
2006-08-17  6:22     ` Andrew Morton
2006-08-17  8:36       ` Jens Axboe
2006-08-17 13:21     ` Trond Myklebust
2006-08-17 15:30       ` Andrew Morton
2006-08-17 16:18         ` Trond Myklebust
2006-08-18  5:34           ` Andrew Morton

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=20060817221717.GV51703024@melbourne.sgi.com \
    --to=dgc@sgi.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®