[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1306111517200.6141@chino.kir.corp.google.com>
Date: Tue, 11 Jun 2013 15:20:09 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Alex Thorlton <athorlton@....com>
cc: linux-kernel@...r.kernel.org, Li Zefan <lizefan@...wei.com>,
Rob Landley <rob@...dley.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Johannes Weiner <hannes@...xchg.org>,
Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>,
linux-doc@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v2] Make transparent hugepages cpuset aware
On Tue, 11 Jun 2013, Alex Thorlton wrote:
> This patch adds the ability to control THPs on a per cpuset basis. Please see
> the additions to Documentation/cgroups/cpusets.txt for more information.
>
What's missing from both this changelog and the documentation you point to
is why this change is needed.
I can understand how you would want a subset of processes to not use thp
when it is enabled. This is typically where MADV_NOHUGEPAGE is used with
some type of malloc hook.
I don't think we need to do this on a cpuset level, so unfortunately I
think this needs to be reworked. Would it make sense to add a per-process
tunable to always get MADV_NOHUGEPAGE behavior for all of its sbrk() and
mmap() calls? Perhaps, but then you would need to justify why it can't be
done with a malloc hook in userspace.
This seems to just be working around a userspace issue or for a matter of
convenience, right?
--
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/
Powered by blists - more mailing lists