[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110420191757.GA5169@Xye>
Date: Thu, 21 Apr 2011 00:47:57 +0530
From: Raghavendra D Prabhu <rprabhu@...hang.net>
To: Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
Cc: linux-mm@...ck.org, Jens Axboe <jaxboe@...ionio.com>,
Christoph Hellwig <hch@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] Add check for dirty_writeback_interval in
bdi_wakeup_thread_delayed
* On Mon, Apr 18, 2011 at 03:26:29PM +0300, Artem Bityutskiy <Artem.Bityutskiy@...ia.com> wrote:
>On Mon, 2011-04-18 at 14:46 +0530, Raghavendra D Prabhu wrote:
>> I have set it to 500 centisecs as that is the default value of
>> dirty_writeback_interval. I used this logic for following reason: the
>> purpose for which dirty_writeback_interval is set to 0 is to disable
>> periodic writeback
>> (http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/fs-writeback.c#L818)
>> , whereas here (in bdi_wakeup_thread_delayed) it is being used for a
>> different purpose -- to delay the bdi wakeup in order to reduce context
>> switches for dirty inode writeback.
>
>But why it wakes up the bdi thread? Exactly to make sure the periodic
>write-back happen.
I checked the callgraph of bdi_wakeup_thread_delayed and found out that
even though it may be called in the aftermath of wb_do_writeback(), it
is certainly called in the call-chain of sync. So effectively making
that function do nothing when dirty_writeback_interval is unset will
also make sync do nothing. On the other hand, not applying the original
change at all will make it run instantly (jiffies + 0, 0 being the
writeback interval in this case ) thus reversing the benefits of
d7dd01adc098eadc5d5fb07a7d2bf942d09b15df.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists