From: Trond Myklebust <trond.myklebust@fys.uio.no>
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: Thu, 17 Aug 2006 09:21:51 -0400 [thread overview]
Message-ID: <1155820912.5662.39.camel@localhost> (raw)
In-Reply-To: <17635.59821.21444.287979@cse.unsw.edu.au>
On Thu, 2006-08-17 at 13:59 +1000, Neil Brown wrote:
> On Tuesday August 15, akpm@osdl.org wrote:
> > > When Dirty hits 0 (and Writeback is theoretically 80% of RAM)
> > > balance_dirty_pages will no longer be able to flush the full
> > > 'write_chunk' (1.5 times number of recent dirtied pages) and so will
> > > spin in a loop calling blk_congestion_wait(WRITE, HZ/10), so it isn't
> > > a busy loop, but it won't progress.
> >
> > This assumes that the queues are unbounded. They're not - they're limited
> > to 128 requests, which is 60MB or so.
>
> Ahhh... so the limit on the requests-per-queue is an important part of
> write-throttling behaviour. I didn't know that, thanks.
>
> fs/nfs doesn't seem to impose a limit. It will just allocate as many
> as you ask for until you start running out of memory. I've seen 60%
> of memory (10 out of 16Gig) in writeback for NFS.
>
> Maybe I should look there to address my current issue, though imposing
> a system-wide writeback limit seems safer.
Exactly how would a request limit help? All that boils down to is having
the VM monitor global_page_state(NR_FILE_DIRTY) versus monitoring
global_page_state(NR_FILE_DIRTY)+global_page_state(NR_WRITEBACK).
Cheers,
Trond
next prev parent reply other threads:[~2006-08-17 13:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-14 23:40 RFC - how to balance Dirty+Writeback in the face of slow writeback 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
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 [this message]
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=1155820912.5662.39.camel@localhost \
--to=trond.myklebust@fys.uio.no \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.