[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111122134155.GA23599@localhost>
Date: Tue, 22 Nov 2011 21:41:55 +0800
From: Wu Fengguang <fengguang.wu@...el.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Jan Kara <jack@...e.cz>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Christoph Hellwig <hch@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/5] writeback: fix dirtied pages accounting on
sub-page writes
On Tue, Nov 22, 2011 at 09:07:50PM +0800, Wu Fengguang wrote:
> On Tue, Nov 22, 2011 at 08:57:42PM +0800, Peter Zijlstra wrote:
> > On Tue, 2011-11-22 at 13:21 +0100, Jan Kara wrote:
> > > > + __get_cpu_var(bdp_ratelimits)++;
> > > I think you need preempt_disable() and preempt_enable() pair around
> > > __get_cpu_var(). Otherwise a process could get rescheduled in the middle of
> > > read-modify-write cycle...
> >
> > there's of course the this_cpu_inc(bdp_ratelimits); thing.
> >
> > On x86 that'll turn into a single insn, on others it will add the
> > required preempt_disable/enable bits.
>
> It's good to know that. But what if we don't really care which CPU
> data it's increasing, and can accept losing some increases due to the
> resulted race condition?
I just added a comment for it, hope it helps :)
/*
* This is racy, however bdp_ratelimits merely serves as a
* gross safeguard. We don't really care the exact CPU it's
* charging to and the resulted inaccuracy is acceptable.
*/
__get_cpu_var(bdp_ratelimits)++;
Thanks,
Fengguang
--
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