linux-kernel - Re: [PATCH v2] Make transparent hugepages cpuset aware

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, 18 Jun 2013 11:45:37 -0500
From:	Alex Thorlton <athorlton@....com>
To:	David Rientjes <rientjes@...gle.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,
	Robin Holt <holt@....com>
Subject: Re: [PATCH v2] Make transparent hugepages cpuset aware

On Tue, Jun 11, 2013 at 03:20:09PM -0700, David Rientjes wrote:
> 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?

David,

Thanks for your input, however, I believe the method of using a malloc
hook falls apart when it comes to static binaries, since we wont' have
any shared libraries to hook into.  Although using a malloc hook is a
perfectly suitable solution for most cases, we're looking to implement a
solution that can be used in all situations.

Aside from that particular shortcoming of the malloc hook solution,
there are some other situations having a cpuset-based option is a
much simpler and more efficient solution than the alternatives.  One
such situation that comes to mind would be an environment where a batch
scheduler is in use to ration system resources.  If an administrator
determines that a users jobs run more efficiently with thp always on,
the administrator can simply set the users jobs to always run with that
setting, instead of having to coordinate with that user to get them to
run their jobs in a different way.  I feel that, for cases such as this,
the this additional flag is in line with the other capabilities that
cgroups and cpusets provide.

While there are likely numerous other situations where having a flag to
control thp on the cpuset level makes things a bit easier to manage, the
one real show-stopper here is that we really have no other options when
it comes to static binaries.

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