From: Eric Sandeen <sandeen@sandeen.net>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Adrian Bunk <bunk@kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Shawn Bohrer <shawn.bohrer@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arjan van de Ven <arjan@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: x86: 4kstacks default
Date: Mon, 21 Apr 2008 08:29:32 -0500 [thread overview]
Message-ID: <480C96BC.4020400@sandeen.net> (raw)
In-Reply-To: <200804210945.24479.vda.linux@googlemail.com>
Denys Vlasenko wrote:
> On Sunday 20 April 2008 16:05, Eric Sandeen wrote:
>> Adrian Bunk wrote:
>>> But the more users will get 4k stacks the more testing we have, and the
>>> better both existing and new bugs get shaken out.
>>>
>>> And if there were only 4k stacks in the vanilla kernel, and therefore
>>> all people on i386 testing -rc kernels would get it, that would give a
>>> better chance of finding stack regressions before they get into a
>>> stable kernel.
>> Heck, maybe you should make it 2k by default in all -rc kernels; that
>> way when people run -final with the 4k it'll be 100% bulletproof, right?
>> 'cause all those piggy drivers that blow a 2k stack will finally have
>> to get fixed? Or leave it at 2k and find a way to share pages for
>> stacks, think how much memory you could save and how many java threads
>> you could run!
>>
>> 4K just happens to be the page size; other than that it's really just
>> some random/magic number picked, and now dictated that if you (and
>> everyting around you) doesn't fit, you're broken.
>
> Some number has to be picked. Why fitting in 4k is "bad" and fitting
> in 8k is "not bad"?
Because well-written code in several subsystems, used in combination in
common configurations, does not always fit, that is why.
Show me the "bug" in an nfs+xfs+md+scsi writeback stack oops and I'm
sure it'll get "fixed." But if it's simply complex code that happens to
need >4k, I will continue to argue that the limited stack size selection
is the problem, not the code running in it.
Perhaps not surprisingly, ext4, which is significantly more complex than
ext3, has many more individual functions > 100 bytes than ext3 has. As
others have said, there is no trend towards smaller, simpler, less
interesting, and less functional code which fits in a smaller and
smaller footprint in the general case.
If someone has a workload and configuration which happens to fit in 4k
then turn it on, test the heck out of it, and have fun. I've not seen
what I consider to be a convincing argument for making it the default
for everyone.
-Eric
next prev parent reply other threads:[~2008-04-21 13:35 UTC|newest]
Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200804181737.m3IHbabI010051@hera.kernel.org>
2008-04-18 21:29 ` x86: 4kstacks default Andrew Morton
2008-04-19 14:23 ` Ingo Molnar
2008-04-19 14:35 ` Oliver Pinter
2008-04-19 15:19 ` Adrian Bunk
2008-04-19 15:42 ` Oliver Pinter
2008-04-20 1:56 ` Eric Sandeen
2008-04-20 7:42 ` Adrian Bunk
2008-04-20 16:59 ` Chris Wedgwood
[not found] ` <480AA2B9.10305__23983.3358479247$1208657639$gmane$org@sandeen.net>
2008-04-20 11:48 ` Andi Kleen
2008-04-19 14:59 ` Shawn Bohrer
2008-04-19 18:00 ` Arjan van de Ven
2008-04-19 18:33 ` Ingo Molnar
2008-04-19 19:10 ` Stefan Richter
2008-04-20 2:36 ` Eric Sandeen
2008-04-20 6:11 ` Arjan van de Ven
2008-04-20 22:53 ` David Chinner
2008-04-20 8:09 ` Adrian Bunk
2008-04-20 8:06 ` Alan Cox
2008-04-20 8:51 ` Adrian Bunk
2008-04-20 9:36 ` Alan Cox
2008-04-20 10:44 ` Adrian Bunk
2008-04-20 11:02 ` Alan Cox
2008-04-20 11:54 ` Adrian Bunk
2008-04-20 11:37 ` Alan Cox
2008-04-20 12:18 ` Adrian Bunk
2008-04-20 14:05 ` Eric Sandeen
2008-04-20 14:21 ` Adrian Bunk
2008-04-20 14:56 ` Eric Sandeen
2008-04-20 15:41 ` Arjan van de Ven
2008-04-20 16:03 ` Adrian Bunk
2008-04-21 3:30 ` Alexander E. Patrakov
2008-04-23 8:57 ` Helge Hafting
2008-04-21 7:45 ` Denys Vlasenko
2008-04-21 9:55 ` Andi Kleen
2008-04-21 13:29 ` Eric Sandeen [this message]
2008-04-21 19:51 ` Denys Vlasenko
2008-04-21 20:28 ` Denys Vlasenko
2008-04-22 1:28 ` David Chinner
2008-04-22 2:33 ` [PATCH] xfs: do not pass size into kmem_free, it's unused Denys Vlasenko
2008-04-22 3:03 ` [PATCH] xfs: do not pass unused params to xfs_flush_pages Denys Vlasenko
2008-04-22 3:14 ` [PATCH] xfs: use smaller int param in call " Denys Vlasenko
2008-04-22 3:18 ` Eric Sandeen
2008-04-22 4:10 ` David Chinner
2008-04-22 9:42 ` [PATCH] xfs: remove unused parameter of xfs_qm_dqpurge Denys Vlasenko
2008-04-22 10:16 ` [PATCH] xfs: remove unused parameter of xfs_iomap_write_allocate Denys Vlasenko
2008-04-22 11:20 ` [PATCH] xfs: #define out unused parameters of xfs_bmap_add_free and xfs_btree_read_bufl Denys Vlasenko
2008-04-22 11:48 ` [PATCH] xfs: #define out unused parameters for seven functions in xfs_trans.h Denys Vlasenko
2008-04-22 11:51 ` Denys Vlasenko
2008-04-22 13:32 ` [PATCH] xfs: remove unused params from functions in xfs_dir2_leaf.h Denys Vlasenko
2008-04-22 13:40 ` [PATCH] xfs: remove unused params from functions in xfs/quota/* Denys Vlasenko
2008-04-22 13:46 ` [PATCH] xfs: expose no-op xfs_put_perag() Denys Vlasenko
2008-04-22 14:08 ` Eric Sandeen
2008-04-22 23:16 ` David Chinner
2008-04-22 23:08 ` [PATCH] xfs: remove unused params from functions in xfs/quota/* David Chinner
2008-04-22 22:47 ` [PATCH] xfs: #define out unused parameters for seven functions in xfs_trans.h David Chinner
2008-04-22 14:28 ` [PATCH] xfs: #define out unused parameters of xfs_bmap_add_free and xfs_btree_read_bufl Adrian Bunk
2008-04-22 16:17 ` Denys Vlasenko
2008-04-22 17:21 ` Adrian Bunk
2008-04-22 17:26 ` Eric Sandeen
2008-04-22 17:50 ` Denys Vlasenko
2008-04-22 18:28 ` [PATCH] xfs: #define out unused parameters of?xfs_bmap_add_free " Adrian Bunk
2008-04-22 19:32 ` Denys Vlasenko
2008-04-22 23:53 ` Adrian Bunk
2008-04-22 20:46 ` [PATCH] xfs: #define out unused parameters of xfs_bmap_add_free " Denys Vlasenko
2008-04-22 22:43 ` David Chinner
2008-04-22 22:33 ` [PATCH] xfs: remove unused parameter of xfs_iomap_write_allocate David Chinner
2008-04-22 22:11 ` [PATCH] xfs: remove unused parameter of xfs_qm_dqpurge David Chinner
2008-04-23 8:18 ` Christoph Hellwig
2008-04-22 22:08 ` [PATCH] xfs: use smaller int param in call to xfs_flush_pages David Chinner
2008-04-22 3:15 ` [PATCH] xfs: do not pass unused params " Eric Sandeen
2008-04-22 8:57 ` Denys Vlasenko
2008-04-22 9:56 ` Jakub Jelinek
2008-04-22 10:33 ` Denys Vlasenko
2008-04-22 12:51 ` Eric Sandeen
2008-04-22 22:07 ` David Chinner
2008-04-22 3:09 ` [PATCH] xfs: do not pass size into kmem_free, it's unused Eric Sandeen
2008-04-22 3:35 ` Eric Sandeen
2008-04-22 22:02 ` David Chinner
2008-04-22 12:48 ` x86: 4kstacks default Denys Vlasenko
2008-04-22 13:01 ` Adrian Bunk
2008-04-22 13:51 ` Denys Vlasenko
2008-04-27 19:27 ` Jörn Engel
2008-04-27 23:02 ` Denys Vlasenko
2008-04-27 23:08 ` Eric Sandeen
2008-04-28 0:00 ` Denys Vlasenko
2008-04-20 12:37 ` Andi Kleen
2008-04-20 12:27 ` Andi Kleen
2008-04-20 12:32 ` Adrian Bunk
2008-04-20 12:47 ` Willy Tarreau
2008-04-20 13:06 ` Andi Kleen
2008-04-20 13:30 ` Adrian Bunk
2008-04-20 13:34 ` Willy Tarreau
2008-04-20 14:04 ` Adrian Bunk
2008-04-28 17:56 ` Bill Davidsen
2008-04-20 13:21 ` Adrian Bunk
2008-04-23 9:13 ` Helge Hafting
2008-04-23 23:29 ` David Chinner
2008-04-24 15:46 ` Eric Sandeen
2008-04-28 18:38 ` Bill Davidsen
2008-04-20 13:27 ` Mark Lord
2008-04-20 13:38 ` Willy Tarreau
2008-04-20 14:19 ` Andi Kleen
2008-04-20 16:41 ` Jörn Engel
2008-04-20 17:19 ` Andi Kleen
2008-04-20 17:43 ` Jörn Engel
2008-04-20 18:19 ` Andi Kleen
2008-04-20 18:50 ` Arjan van de Ven
2008-04-20 20:09 ` Andi Kleen
2008-04-20 21:50 ` Andrew Morton
2008-04-20 21:55 ` Andi Kleen
2008-04-21 14:29 ` Ingo Molnar
2008-04-20 20:32 ` Jörn Engel
2008-04-20 20:35 ` Jörn Engel
2008-04-20 14:09 ` Eric Sandeen
2008-04-20 14:20 ` Willy Tarreau
2008-04-20 14:40 ` Eric Sandeen
2008-04-20 15:44 ` Daniel Hazelton
2008-04-20 17:26 ` Andi Kleen
2008-04-20 18:48 ` Arjan van de Ven
2008-04-20 20:01 ` Andi Kleen
2008-04-20 20:43 ` Daniel Hazelton
2008-04-20 21:40 ` Andi Kleen
2008-04-20 22:17 ` Bernd Eckenfels
2008-04-20 23:48 ` Avi Kivity
2008-04-21 1:45 ` Daniel Hazelton
2008-04-21 7:51 ` Andi Kleen
2008-04-21 17:34 ` Daniel Hazelton
2008-04-20 22:33 ` Arjan van de Ven
2008-04-20 22:33 ` Arjan van de Ven
2008-04-20 23:16 ` Andi Kleen
2008-04-21 5:53 ` Arjan van de Ven
2008-04-21 3:06 ` Eric Sandeen
2008-04-20 21:45 ` Andrew Morton
2008-04-20 21:51 ` Andi Kleen
2008-04-22 18:20 ` Romano Giannetti
2008-04-23 5:03 ` Denys Vlasenko
2008-04-23 5:21 ` Daniel Hazelton
2008-04-23 5:25 ` david
2008-04-23 5:41 ` Daniel Hazelton
2008-04-23 7:46 ` Romano Giannetti
2008-04-23 11:24 ` Stefan Richter
2008-04-23 12:15 ` Romano Giannetti
2008-04-23 15:59 ` Lennart Sorensen
2008-04-20 13:22 ` Mark Lord
2008-04-19 17:49 ` Andrew Morton
2008-04-25 17:39 ` Parag Warudkar
2008-04-20 3:29 ` Eric Sandeen
2008-04-20 12:36 ` Andi Kleen
2008-04-21 14:31 ` Ingo Molnar
2008-04-23 5:27 ` Benjamin Herrenschmidt
2008-04-23 23:36 ` David Chinner
2008-04-24 0:45 ` Arjan van de Ven
2008-04-24 9:52 ` Christoph Hellwig
2008-04-24 12:25 ` Peter Zijlstra
2008-04-24 15:41 ` Chris Mason
2008-04-24 18:30 ` Alexander van Heukelum
2008-04-24 0:56 ` Benjamin Herrenschmidt
[not found] <ak6tq-32p-7@gated-at.bofh.it>
[not found] ` <ak6tq-32p-5@gated-at.bofh.it>
2008-04-19 10:56 ` Bodo Eggert
[not found] ` <akFri-4yB-25@gated-at.bofh.it>
[not found] ` <akGQg-7TX-1@gated-at.bofh.it>
[not found] ` <akKhi-91-37@gated-at.bofh.it>
2008-04-20 20:23 ` Bodo Eggert
2008-04-20 20:59 ` Daniel Hazelton
2008-04-21 20:05 ` Bodo Eggert
2008-04-22 15:34 ` Daniel Hazelton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=480C96BC.4020400@sandeen.net \
--to=sandeen@sandeen.net \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=bunk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=shawn.bohrer@gmail.com \
--cc=tglx@linutronix.de \
--cc=vda.linux@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox