linux-kernel - Re: [PATCH] vmscan: Do reclaim stall in case of mlocked page.

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 2 Sep 2011 11:19:49 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	Johannes Weiner <jweiner@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-mm <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: Re: [PATCH] vmscan: Do reclaim stall in case of mlocked page.

On Thu, Sep 1, 2011 at 2:30 AM, Johannes Weiner <jweiner@...hat.com> wrote:
> On Tue, Nov 15, 2011 at 12:37:23AM +0900, Minchan Kim wrote:
>> [1] made avoid unnecessary reclaim stall when second shrink_page_list(ie, synchronous
>> shrink_page_list) try to reclaim page_list which has not-dirty pages.
>> But it seems rather awkawrd on unevictable page.
>> The unevictable page in shrink_page_list would be moved into unevictable lru from page_list.
>> So it would be not on page_list when shrink_page_list returns.
>> Nevertheless it skips reclaim stall.
>>
>> This patch fixes it so that it can do reclaim stall in case of mixing mlocked pages
>> and writeback pages on page_list.
>>
>> [1] 7d3579e,vmscan: narrow the scenarios in whcih lumpy reclaim uses synchrounous reclaim
>
> Lumpy isolates physically contiguous in the hope to free a bunch of
> pages that can be merged to a bigger page.  If an unevictable page is
> encountered, the chance of that is gone.  Why invest the allocation
> latency when we know it won't pay off anymore?
>

Good point!

Except some cases, when we require higher orer page, we used zone
defensive algorithm by zone_watermark_ok. So the number of fewer
higher order pages would be factor of failure of allocation. If it was
problem, we could rescue the situation by only reclaim part of the
block in the hope to free fewer higher order pages.

I thought the lumpy was designed to consider the case.(I might be wrong).
Why I thought is that when we isolate the pages for lumpy and found
the page isn't able to isolate, we don't rollback the isolated pages
in the lumpy phsyical block. It's very pointless to get a higher order
pages.

If we consider that, we have to fix other reset_reclaim_mode cases as
well as mlocked pages.
Or
fix isolataion logic for the lumpy? (When we find the page isn't able
to isolate, rollback the pages in the lumpy block to the LRU)
Or
Nothing and wait to remove lumpy completely.

What do you think about it?

-- 
Kind regards,
Minchan Kim
--
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/