linux-kernel - Re: [RFC PATCH] mm: thp: Add per-mm

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: <alpine.DEB.2.02.1401221343580.22014@chino.kir.corp.google.com>
Date:	Wed, 22 Jan 2014 13:46:04 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Alex Thorlton <athorlton@....com>
cc:	Mel Gorman <mgorman@...e.de>,
	Peter Zijlstra <peterz@...radead.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>, linux-mm@...ck.org,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Rik van Riel <riel@...hat.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Oleg Nesterov <oleg@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andy Lutomirski <luto@...capital.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	Kees Cook <keescook@...omium.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mm: thp: Add per-mm_struct flag to control THP

On Wed, 22 Jan 2014, Alex Thorlton wrote:

> > I would expect that the alternative solution to a per-mm switch is to
> > reserve the naturally aligned pages for a THP promotion. Have a threshold
> > of pages pages that must be faulted before the full THP's worth of pages
> > is allocated, zero'd and a huge pmd established. That would defer the
> > THP setup costs until it was detected that it was necessary.
> 
> I have some half-finished patches that I was working on a month or so
> ago, to do exactly this (I think you were involved with some of the
> discussion, maybe?  I'd have to dig up the e-mails to be sure).  After
> cycling through numerous other methods of handling this problem, I still
> like that idea, but I think it's going to require a decent amount of
> effort to get finished.  
> 

If you're going to go this route, I think a sane value would be 
max_ptes_none that controls when khugepaged would re-collapse a split 
hugepage into another hugepage after something does madvise(MADV_DONTNEED) 
to a region, for example.  Otherwise it could collapse that memory into a 
hugepage even though it wasn't faulted as huge.
--
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/