linux-kernel - [PATCH 0/2] Avoid excessive reclaim due to THP

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

Date:	Fri,  7 Oct 2011 16:17:21 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>, akpm@...ux-foundation.org
Cc:	Josh Boyer <jwboyer@...hat.com>, aarcange@...hat.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] Avoid excessive reclaim due to THP

The thread "[PATCH v2 -mm] limit direct reclaim for higher order
allocations" went silent so this is an attempt to kick it awake again
to close it.

Rik noticed that there was too much memory free on his machine when
THP was running and there is at least one bug report out there that
implies that reclaim due to khugepaged is causing stalls.

In Rik's case, he posted a patch that fixed his
problem. The user on the RH bug reported that a patch from
https://lkml.org/lkml/2011/7/26/103 fixed his problem. However, in many
cases, these patches are complimentary except that Rik's is tidier.

Patch 1 of this series is a patch from Rik that limits the amount
of direct reclaim that occurs as a result of THP. Specifically,
if compaction can go ahead in a zone or is deferred for a zonelist,
then reclaim will stop as it is unlikely freeing more pages will help.

Patch 2 notes that even if patch 1 stops reclaiming, the caller
of shrink_zones will still shrink slabs and scan at the next
priority.  This is unnecessary and wasteful so the patch causes
do_try_to_free_pages() to abort reclaim if shrink_zones() returned
early.

Rik, can you retest with your case just to be sure? Josh, will you
ask the reporter of RH#735946 to retest with these patches to ensure
their problem really gets fixed upstream?

I tested it myself and it appears to behave as expected. Performance
of benchmarks like STREAM that benefit from THP are unchanged
as expected. When running with a basic workload that created a
large anonymous mapping and read it multiple times followed by
writing it multiple times, there are fewer pages direct reclaimed.
Critically, memory utilisation is higher with these patches applied
as predicted. In the vanilla kernel, I can see a few spikes where an
excessive amount of memory memory was reclaimed that is not present
with the patches applied.

Are there any objections to these being merged?

 mm/vmscan.c |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

-- 
1.7.3.4

--
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/