linux-kernel - Re: [PATCH 03/31] huge tmpfs: huge=N mount option and /proc/sys/vm/shmem

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: <20160411111705.GE22996@node.shutemov.name>
Date:	Mon, 11 Apr 2016 14:17:05 +0300
From:	"Kirill A. Shutemov" <kirill@...temov.name>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Andres Lagar-Cavilla <andreslc@...gle.com>,
	Yang Shi <yang.shi@...aro.org>, Ning Qu <quning@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 03/31] huge tmpfs: huge=N mount option and
 /proc/sys/vm/shmem_huge

On Tue, Apr 05, 2016 at 02:15:05PM -0700, Hugh Dickins wrote:
> Plumb in a new "huge=1" or "huge=0" mount option to tmpfs: I don't
> want to get into a maze of boot options, madvises and fadvises at
> this stage, nor extend the use of the existing THP tuning to tmpfs;
> though either might be pursued later on.  We just want a way to ask
> a tmpfs filesystem to favor huge pages, and a way to turn that off
> again when it doesn't work out so well.  Default of course is off.
> 
> "mount -o remount,huge=N /mountpoint" works fine after mount:
> remounting from huge=1 (on) to huge=0 (off) will not attempt to
> break up huge pages at all, just stop more from being allocated.
> 
> It's possible that we shall allow more values for the option later,
> to select different strategies (e.g. how hard to try when allocating
> huge pages, or when to map hugely and when not, or how sparse a huge
> page should be before it is split up), either for experiments, or well
> baked in: so use an unsigned char in the superblock rather than a bool.

Make the value a string from beginning would be better choice in my
opinion. As more allocation policies would be implemented, number would
not make much sense.

For record, my implementation has four allocation policies: never, always,
within_size and advise.

> 
> No new config option: put this under CONFIG_TRANSPARENT_HUGEPAGE,
> which is the appropriate option to protect those who don't want
> the new bloat, and with which we shall share some pmd code.  Use a
> "name=numeric_value" format like most other tmpfs options.  Prohibit
> the option when !CONFIG_TRANSPARENT_HUGEPAGE, just as mpol is invalid
> without CONFIG_NUMA (was hidden in mpol_parse_str(): make it explicit).
> Allow setting >0 only if the machine has_transparent_hugepage().
> 
> But what about Shmem with no user-visible mount?  SysV SHM, memfds,
> shared anonymous mmaps (of /dev/zero or MAP_ANONYMOUS), GPU drivers'
> DRM objects, ashmem.  Though unlikely to suit all usages, provide
> sysctl /proc/sys/vm/shmem_huge to experiment with huge on those.  We
> may add a memfd_create flag and a per-file huge/non-huge fcntl later.

I use sysfs knob instead:

/sys/kernel/mm/transparent_hugepage/shmem_enabled

And string values there as well. It's better match current THP interface.

> And allow shmem_huge two further values: -1 for use in emergencies,
> to force the huge option off from all mounts; and (currently) 2,
> to force the huge option on for all - very useful for testing.

In my case, it's "deny" and "force".

-- 
 Kirill A. Shutemov