linux-kernel - Re: [PATCH 1/3] mm: completely disable THP by transparent

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: <20110622142239.GV20843@redhat.com>
Date:	Wed, 22 Jun 2011 16:22:39 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Cong Wang <amwang@...hat.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, Rik van Riel <riel@...hat.com>,
	Mel Gorman <mgorman@...e.de>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, Johannes Weiner <jweiner@...hat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-mm@...ck.org
Subject: Re: [PATCH 1/3] mm: completely disable THP by
 transparent_hugepage=never

On Wed, Jun 22, 2011 at 10:56:41AM +0800, Cong Wang wrote:
> 于 2011年06月21日 22:43, Andrea Arcangeli 写道:
> > On Tue, Jun 21, 2011 at 12:08:14PM +0800, Cong Wang wrote:
> >> The thing is that we can save ~10K by adding 3 lines of code as this
> >> patch showed, where else in kernel can you save 10K by 3 lines of code?
> >> (except some kfree() cases, of course) So, again, why not have it? ;)
> >
> > Because you could save it with a more complicated patch that doesn't
> > cripple down functionality.
> 
> 
> Why do you prefer "more complicated" things to simple ones? ;-)

If they offer more features yes. Allowing to tune the size of the has
will also allow to increase it, not only to decrease it. It's also not
significantly more complicated.

> I realized this patch changed the original behavior of "=never",
> thus proposed a new "=0" parameter.
> 
> But to be honest, "=never" should be renamed to "=disable".

So in turn you're saying "=always" should be renamed to "=enabled". So
your preference would be enabled=enabled and enabled=disabled and
enabled=madvise? I think the current wording is nicer and breaking
kabi just for this sounds bad.

> Not only such things, the more serious thing is that you are
> enforcing a policy to users, as long as I enable THP in Kconfig,
> I have no way to disable it.
> 
> Why are you so sure that every user who has no chance to change
> .config likes THP?
> 
> And, what can I do if I want to prevent any process from having
> a chance to enable THP? Because as long as THP exists in /sys,
> any process has the right privilege can change it.

You must be root to have the privilege to enable it, root also has the
privilege to enable THP by writing in /dev/mem or by loading a kernel
module to do it.

I already told you how to save hundred kbytes of ram from you kernel
setting dhash_entries=1 and ihash_entries=1 and how to achieve the ~8k
ram saving in THP and KSM without crippling functionality with a patch
that is more complex than your three liner, but not much more complex,
and that it will _improve_ (not cripple down) functionality.

I'm also not interested into making the 512M param configurable. If
you want to add a "=force" parameter ok but I doubt you will ever gain
anything significant on a system with 512M of ram where each process
will likely be smaller than 512M and 100M would get used by the
anti-frag logic (reducing it to 400m).

I suggest just cleaning up the printk and if you want you can add a
__setup("thp_mm_slots_hash_heads=", set_thp_mm_slots_hash_heads) but
no other change needed.
--
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/