[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160229173312.GK16930@dhcp22.suse.cz>
Date: Mon, 29 Feb 2016 18:33:12 +0100
From: Michal Hocko <mhocko@...nel.org>
To: "Shi, Yang" <yang.shi@...aro.org>
Cc: tj@...nel.org, jack@...e.cz, axboe@...com, fengguang.wu@...el.com,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linaro-kernel@...ts.linaro.org
Subject: Re: [RFC PATCH] writeback: move list_lock down into the for loop
On Mon 29-02-16 09:27:44, Shi, Yang wrote:
> On 2/29/2016 7:06 AM, Michal Hocko wrote:
> >On Fri 26-02-16 08:46:25, Yang Shi wrote:
> >>The list_lock was moved outside the for loop by commit
> >>e8dfc30582995ae12454cda517b17d6294175b07 ("writeback: elevate queue_io()
> >>into wb_writeback())", however, the commit log says "No behavior change", so
> >>it sounds safe to have the list_lock acquired inside the for loop as it did
> >>before.
> >>Leave tracepoints outside the critical area since tracepoints already have
> >>preempt disabled.
> >
> >The patch says what but it completely misses the why part.
>
> I'm just wondering the finer grained lock may reach a little better
> performance, i.e. more likely for preempt, lower latency.
If this is supposed to be a performance enhancement then some numbers
would definitely make it easier to get in. Or even an arguments to back
your theory. Basing your argument on 4+ years commit doesn't really seem
sound... Just to make it clear, I am not opposing the patch I just
stumbled over it and the changelog was just too terrible which made me
response.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists