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:	Wed, 22 Jun 2011 16:40:57 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Cong Wang <amwang@...hat.com>
Cc:	David Rientjes <rientjes@...gle.com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	dave@...ux.vnet.ibm.com, Mel Gorman <mel@....ul.ie>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-mm@...ck.org
Subject: Re: [PATCH v2 2/4] mm: make the threshold of enabling THP
 configurable

On Wed, Jun 22, 2011 at 07:07:25PM +0800, Cong Wang wrote:
> Actually, if we move this out of kernel, to user-space, everything
> you worried will be solved by just changing the user-space code.
> Just add the following pseudo code into your init script,
> 
> if [ $total_memory -lt 512 ]
> then
> 	echo never > /sys/kernel/mm/transparent_hugepage/enabled
> fi

By the time this script runs some app may have allocated hugepages
already potentially wasting mbytes of ram and undoing the
min_free_kbytes isn't possible from userland using the kernel
algorithm (it is possible actually but it's not nearly as simple as
the above).

There's no reason to complicate things and involve userland here when
a simple kernel check can get the default right without userland
dependency. Plus if this user really wants THP on 512m of ram he can
still enable it and run hugeadm to enable antifrag too, without the
need of =force. And forcing when PSE is enabled sounds impossible to be
useful (maybe with the except of nopentium being passed to the kernel ;).

There is no bug here, just send that printk cleanup and if you really
want to save 8k the patch to change the number of hash heads structs
at boot, like for dcache/icache. No other change required.

After you do the above, you can go ahead picking one kernel crashing
bug and fix it, that is more useful than making this 512m thing a
.config variable or anything like that, .config is a nightmare already
so it's probably better not to add anything there.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ