[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1252434510.7035.4.camel@laptop>
Date: Tue, 08 Sep 2009 20:28:30 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Chris Mason <chris.mason@...cle.com>
Cc: Artem Bityutskiy <dedekind1@...il.com>,
Jens Axboe <jens.axboe@...cle.com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
david@...morbit.com, hch@...radead.org, akpm@...ux-foundation.org,
jack@...e.cz, Theodore Ts'o <tytso@....edu>,
Wu Fengguang <fengguang.wu@...el.com>
Subject: Re: [PATCH 8/8] vm: Add an tuning knob for vm.max_writeback_mb
On Tue, 2009-09-08 at 13:57 -0400, Chris Mason wrote:
> Going back to the streaming writer case, pretend the FS just created a
> nice fat 256MB extent out of dealloc pages, but after we wrote the first
> 4k, we dropped below the dirty threshold and IO is no longer "required".
>
> It would be silly to just write 4k. We know we have a contiguous
> area 256MB long on disk and 256MB of dirty pages. In this case, pdflush
> (or Jens' bdi threads) want to write some large portion of that 256MB.
>
> You might argue a balance_dirty_pages callers wants to return quickly,
> but even then we'd want to write at least 128k.
Sure and that's no problem at all,.. I'm thinking something like a
fraction of the dirty limit, maybe something like
(dirty_ratio-background_ratio) / 4 as chunk size. That gives a sizable
amount and scales with the writeback cache stuff.
Esp if we move all write activity into the bdi threads and have the
application tasks wait. In that case we can release the app tasks to
generate more dirty pages while still writing out data in a linear
fashion.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists