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]

Message-Id: <20111114154408.10de1bc7.akpm@linux-foundation.org>
Date:	Mon, 14 Nov 2011 15:44:08 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Mel Gorman <mgorman@...e.de>
Cc:	David Rientjes <rientjes@...gle.com>,
	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 Fri, 11 Nov 2011 10:14:14 +0000
Mel Gorman <mgorman@...e.de> wrote:

> On Thu, Nov 10, 2011 at 03:37:32PM -0800, David Rientjes wrote:
> > On Thu, 10 Nov 2011, Andrew Morton wrote:
> > 
> > > > This patch once again prevents sync migration for transparent
> > > > hugepage allocations as it is preferable to fail a THP allocation
> > > > than stall.
> > > 
> > > Who said?  ;) Presumably some people would prefer to get lots of
> > > huge pages for their 1000-hour compute job, and waiting a bit to get
> > > those pages is acceptable.
> > > 
> > 
> > Indeed.  It seems like the behavior would better be controlled with 
> > /sys/kernel/mm/transparent_hugepage/defrag which is set aside specifically 
> > to control defragmentation for transparent hugepages and for that 
> > synchronous compaction should certainly apply.
> 
> With khugepaged in place, it's adding a tunable that is unnecessary and
> will not be used. Even if such a tuneable was created, the default
> behaviour should be "do not stall".

(who said?)

Let me repeat my cruelly unanswered question: do we have sufficient
instrumentation in place so that operators can determine that this
change is causing them to get less huge pages than they'd like?

Because some people really really want those huge pages.  If we go and
silently deprive them of those huge pages via changes like this, how do
they *know* it's happening?

And what are their options for making the kernel try harder to get
those pages?

And how do we communicate all of this to those operators?
--
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/