linux-kernel - Re: [PATCH 1/2] mm: vmscan: Remove lumpy reclaim

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALWz4iw7aTi9mVos98SuLe_vibmhrY19oQvMN36aBwp0exH7DQ@mail.gmail.com>
Date:	Tue, 10 Apr 2012 10:25:23 -0700
From:	Ying Han <yinghan@...gle.com>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Linux-MM <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH 1/2] mm: vmscan: Remove lumpy reclaim

On Tue, Apr 10, 2012 at 2:29 AM, Mel Gorman <mgorman@...e.de> wrote:
> On Tue, Apr 10, 2012 at 09:24:54AM +0100, Mel Gorman wrote:
>> On Fri, Apr 06, 2012 at 04:52:09PM -0700, Ying Han wrote:
>> > On Wed, Mar 28, 2012 at 9:06 AM, Mel Gorman <mgorman@...e.de> wrote:
>> > > Lumpy reclaim had a purpose but in the mind of some, it was to kick
>> > > the system so hard it trashed. For others the purpose was to complicate
>> > > vmscan.c. Over time it was giving softer shoes and a nicer attitude but
>> > > memory compaction needs to step up and replace it so this patch sends
>> > > lumpy reclaim to the farm.
>> > >
>> > > Here are the important notes related to the patch.
>> > >
>> > > 1. The tracepoint format changes for isolating LRU pages.
>> > >
>> > > 2. This patch stops reclaim/compaction entering sync reclaim as this
>> > >   was only intended for lumpy reclaim and an oversight. Page migration
>> > >   has its own logic for stalling on writeback pages if necessary and
>> > >   memory compaction is already using it. This is a behaviour change.
>> > >
>> > > 3. RECLAIM_MODE_SYNC no longer exists. pageout() does not stall
>> > >   on PageWriteback with CONFIG_COMPACTION has been this way for a while.
>> > >   I am calling it out in case this is a surpise to people.
>> >
>> > Mel,
>> >
>> > Can you point me the commit making that change? I am looking at
>> > v3.4-rc1 where set_reclaim_mode() still set RECLAIM_MODE_SYNC for
>> > COMPACTION_BUILD.
>> >
>>
>> You're right.
>>
>> There is only one call site that passes sync==true for set_reclaim_mode() in
>> vmscan.c and that is only if should_reclaim_stall() returns true. It had the
>> comment "Only stall on lumpy reclaim" but the comment is not accurate
>> and that mislead me.
>>
>> Thanks, I'll revisit the patch.
>>
>
> Just to be clear, I think the patch is right in that stalling on page
> writeback was intended just for lumpy reclaim.

I see mismatch between the comment "Only stall on lumpy reclaim" and
the actual implementation in should_reclaim_stall(). Not sure what is
intended, but based on the code, both lumpy and compaction reclaim
will be stalled under PageWriteback.

I've split out the patch
> that stops reclaim/compaction entering sync reclaim but the end result
> of the series is the same.

I think that make senses to me for compaction due to its migrating page nature.

Unfortunately we do not have tracing to record
> how often reclaim waited on writeback during compaction so my historical
> data does not indicate how often it happened. However, it may partially
> explain occasionaly complaints about interactivity during heavy writeback
> when THP is enabled (the bulk of the stalls were due to something else but
> on rare occasions disabling THP was reported to make a small unquantifable
> difference). I'll enable ftrace to record how often mm_vmscan_writepage()
> used RECLAIM_MODE_SYNC during tests for this series and include that
> information in the changelog.

Thanks for looking into it.

--Ying

> --
> Mel Gorman
> SUSE Labs
--
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/