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:	Sun, 15 Jul 2007 10:35:17 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	7eggert@....de
Cc:	Matt Mackall <mpm@...enic.com>,
	Rene Herman <rene.herman@...il.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Jesper Juhl <jesper.juhl@...il.com>,
	Ray Lee <ray-lk@...rabbit.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	William Lee Irwin III <wli@...omorphy.com>,
	David Chinner <dgc@....com>
Subject: Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

On Sun, 2007-07-15 at 19:17 +0200, Bodo Eggert wrote:
> Matt Mackall <mpm@...enic.com> wrote:
> > On Fri, Jul 13, 2007 at 03:20:54PM +0200, Rene Herman wrote:
> 
> >> As far as I'm aware, the actual reason for 4K stacks is that after the
> >> system has been up and running for some time getting "1 physically
> >> contiguous pages" becomes significantly easier than 2 which wouldn't be
> >> arbitrary.
> > 
> > If there are exactly two free pages in the system, the odds of them
> > being buddies (ie adjacent AND properly aligned) is quite small. The
> > available page pool has to grow quite a bit before the availability of
> > order-1 page pairs approaches 100%.
> 
> If there are exactly two free pages in a system, the odds of starting any
> program are not very good. You'll have to swap, and if you do, you can swap
> two more pages in order to free enough RAM for the stack.


even if you have several thousand pages the odds aren't good; or rather,
they start out reasonably ok until something starts eating very
deliberately at the 8k pages pool, for example the new app creating
about 10 threads....

The 4K issue is "tricky", only a few selected workload/compiler combos
seem to hit the dirt, yet distros like Fedora and RHEL use 4K stacks
since forever, and if it gave massive problems they wouldn't do that.
On the upside, especially on very-threaded workloads, it helps
reliability and the VM a lot...


-
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