All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Chris Mason <chris.mason@oracle.com>,
	Andrew Morton <akpm@osdl.org>, David Chinner <dgc@sgi.com>,
	Michael Rubin <mrubin@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] [RFC][PATCH] clustered writeback
Date: Mon, 27 Aug 2007 20:27:38 +0800	[thread overview]
Message-ID: <388217659.90061@ustc.edu.cn> (raw)
Message-ID: <20070827122738.GA6999@mail.ustc.edu.cn> (raw)
In-Reply-To: <20070827050336.6a7e8e16@laptopd505.fenrus.org>

On Mon, Aug 27, 2007 at 05:03:36AM -0700, Arjan van de Ven wrote:
> On Mon, 27 Aug 2007 19:21:52 +0800
> > 
> > Because it does the work in small batches of 10 inodes, when the
> > system has <=10 dirty inodes, its behavior will reduce to:
> > - do a full sweep *at once* on every 25s
> > Which means the disk will flicker once every 25s, not bad :)
> 
> 25 seconds is quite not good already though.... it takes a disk a
> second or two of no activity to go into low power mode, every 25
> seconds means you now have at least a 10% constant power cost....
> 
> I don't know the right answer (well other than "make sure inodes aren't
> dirty", which involves fixing apps to not do as much file operations,
> as well as relatime) but just "every 25s is no big deal" isn't really
> the case ;-(

Yeah, 25s may be too frequent... What I meant is that the old behavior
could be "write 1-3 inodes on every 5s" if the inodes are dirtied at
random times. Now it becomes "write 10 inodes on every 25s". So it is
actually better ;-)

It's interesting that we want writeback to be smooth on heavy loads
and to be 'bursty' on light loads. Increasing dirty_expire_centisecs
and decreasing dirty_writeback_centisecs could help it somehow.


  reply	other threads:[~2007-08-27 12:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-27 11:21 [PATCH 0/3] [RFC][PATCH] clustered writeback Fengguang Wu
2007-08-27 11:21 ` Fengguang Wu
2007-08-27 12:03   ` Arjan van de Ven
2007-08-27 12:27     ` Fengguang Wu [this message]
2007-08-27 12:27       ` Fengguang Wu
2007-08-27 12:43     ` Chris Mason
2007-08-27 11:21 ` [PATCH 1/3] writeback: introduce queue_dirty() Fengguang Wu
2007-08-27 11:21   ` Fengguang Wu
2007-08-27 11:21 ` [PATCH 2/3] writeback: introduce dirty_volatile_interval Fengguang Wu
2007-08-27 11:21   ` Fengguang Wu
2007-08-27 11:21 ` [PATCH 3/3] writeback: writeback clustering by inode number Fengguang Wu
2007-08-27 11:21   ` Fengguang Wu

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=388217659.90061@ustc.edu.cn \
    --to=wfg@mail.ustc.edu.cn \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=chris.mason@oracle.com \
    --cc=dgc@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrubin@google.com \
    /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.