linux-kernel - Re: x86: 4kstacks default

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: <20080421075102.GB14446@one.firstfloor.org>
Date:	Mon, 21 Apr 2008 09:51:02 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Daniel Hazelton <dhazelton@...er.net>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Adrian Bunk <bunk@...nel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Shawn Bohrer <shawn.bohrer@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: x86: 4kstacks default

> Never said it worked on a 32bit system. I was pointing out that there can be 
> workloads that do reach 

Ah your point was that people might do this on 64bit systems? 

They could indeed. It would not be very efficient but it should work
in theory at least with enough memory. Of course they don't need 4k
stacks for it. They can also try it on 32bit and it will work
to some extent too, just not scale very far.  And 4k stack more or less
won't make much difference for that because the stack is only
a small part of the lowmem needed for a blocked thread with
open sockets.

But this thread clearly was about 32bit systems only.

> that 50K thread-count that you seem to be 
> calling "stupid". 

Note I didn't come up with that number, it was quoted to me earlier
(but one of its authors has distanced itself from it now, so it 
seems to becoming more and more irrelevant indeed now) 

Stupid in this case just refers to the general observation that
it is quite inefficient to do one thread per request on servers
who are expected to process lots of long running connections.

Perhaps I could have put that better I will give you that. Please
assume I always meant "inefficient" when I wrote "stupid".

> talking about. If I had been running 4K stacks on that machine I probably 
> would have survived the mis-configuration without the reboot it took to make 

Now that is a very doubtful claim. You realize that a functional network
server thread needs a lot more lowmem than just the stack? 

-Andi

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