[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140530074145.GA2688@kernel.org>
Date: Fri, 30 May 2014 15:41:45 +0800
From: Shaohua Li <shli@...nel.org>
To: Hugh Dickins <hughd@...gle.com>
Cc: Chen Yucong <slaoub@...il.com>, akpm@...ux-foundation.org,
ddstreet@...e.org, mgorman@...e.de, k.kozlowski@...sung.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] swap: Avoid scanning invalidated region for cheap seek
On Tue, May 27, 2014 at 08:53:00PM -0700, Hugh Dickins wrote:
> On Mon, 26 May 2014, Chen Yucong wrote:
>
> > For cheap seek, when we scan the region between si->lowset_bit
> > and scan_base, if san_base is greater than si->highest_bit, the
> > scan operation between si->highest_bit and scan_base is not
> > unnecessary.
> >
> > This patch can be used to avoid scanning invalidated region for
> > cheap seek.
> >
> > Signed-off-by: Chen Yucong <slaoub@...il.com>
>
> I was going to suggest that you are adding a little code to a common
> path, in order to optimize a very unlikely case: which does not seem
> worthwhile to me.
>
> But digging a little deeper, I think you have hit upon something more
> interesting (though still in no need of your patch): it looks to me
> like that is not even a common path, but dead code.
>
> Shaohua, am I missing something, or does all SWP_SOLIDSTATE "seek is
> cheap" now go your si->cluster_info scan_swap_map_try_ssd_cluster()
> route? So that the "last_in_cluster < scan_base" loop in the body
> of scan_swap_map() is just redundant, and should have been deleted?
Sorry for the delay, you are right. SSD case always goes
scan_swap_map_try_ssd_cluster, otherwise we just scan from lowest_bit to
highest_bit, so the "last_in_cluster < scan_base" loop is dead.
Yucong, can you resent a patch to delete it as Hugh suggested?
Thanks,
Shaohua
--
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