linux-kernel - Re: [PATCH] mm: Do not stall in synchronous compaction for THP allocations

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:	Tue, 15 Nov 2011 13:07:51 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Mel Gorman <mgorman@...e.de>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan.kim@...il.com>, Jan Kara <jack@...e.cz>,
	Andy Isaacson <adi@...apodia.org>,
	Johannes Weiner <jweiner@...hat.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: Do not stall in synchronous compaction for THP
 allocations

On Tue, 15 Nov 2011, Mel Gorman wrote:

> Fine control is limited. If it is really needed, I would not oppose
> a patch that allows the use of sync compaction via a new setting in
> /sys/kernel/mm/transparent_hugepage/defrag. However, I think it is
> a slippery slope to expose implementation details like this and I'm
> not currently planning to implement such a patch.
> 

This doesn't expose any implementation detail, the "defrag" tunable is 
supposed to limit defragmentation efforts in the VM if the hugepages 
aren't immediately available and simply fallback to using small pages.  
Given that definition, it would make sense to allow for synchronous 
defragmentation (i.e. sync_compaction) on the second iteration of the page 
allocator slowpath if set.  So where's the disconnect between this 
proposed behavior and the definition of the tunable in 
Documentation/vm/transhuge.txt?
--
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/