From: Bill Davidsen <davidsen@tmr.com>
To: Rik van Riel <riel@redhat.com>
Cc: Christoph Lameter <clameter@sgi.com>, Andi Kleen <ak@suse.de>,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, travis@sgi.com
Subject: Re: [13/18] x86_64: Allow fallback for the stack
Date: Sat, 06 Oct 2007 14:53:40 -0400 [thread overview]
Message-ID: <4707D9B4.8020904@tmr.com> (raw)
In-Reply-To: <20071004153940.49bd5afc@bree.surriel.com>
Rik van Riel wrote:
> On Thu, 4 Oct 2007 12:20:50 -0700 (PDT)
> Christoph Lameter <clameter@sgi.com> wrote:
>
>> On Thu, 4 Oct 2007, Andi Kleen wrote:
>>
>>> We've known for ages that it is possible. But it has been always so
>>> rare that it was ignored.
>> Well we can now address the rarity. That is the whole point of the
>> patchset.
>
> Introducing complexity to fight a very rare problem with a good
> fallback (refusing to fork more tasks, as well as lumpy reclaim)
> somehow does not seem like a good tradeoff.
>
>>> Is there any evidence this is more common now than it used to be?
>> It will be more common if the stack size is increased beyond 8k.
>
> Why would we want to do such a thing?
>
> 8kB stacks are large enough...
>
Why would anyone need more than 640k... In addition to NUMA, who can
tell what some future hardware might do, given that the size of memory
is expanding as if it were covered in Moore's Law. As memory sizes
increase someone will bump the page size again. Better to Let people
make it as large as they feel they need and warn at build time
performance may suck.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-10-06 18:53 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 3:59 [00/18] Virtual Compound Page Support V2 Christoph Lameter
2007-10-04 3:59 ` [01/18] vmalloc: clean up page array indexing Christoph Lameter
2007-10-04 3:59 ` [02/18] vunmap: return page array passed on vmap() Christoph Lameter
2007-10-04 3:59 ` [03/18] vmalloc_address(): Determine vmalloc address from page struct Christoph Lameter
2007-10-04 3:59 ` [04/18] Vcompound: Smart up virt_to_head_page() Christoph Lameter
2007-10-04 3:59 ` [05/18] Page flags: Add PageVcompound() Christoph Lameter
2007-10-04 3:59 ` [06/18] Vcompound: Update page address determination Christoph Lameter
2007-10-04 3:59 ` [07/18] Vcompound: Add compound_nth_page() to determine nth base page Christoph Lameter
2007-10-04 3:59 ` [08/18] GFP_VFALLBACK: Allow fallback of compound pages to virtual mappings Christoph Lameter
2007-10-04 3:59 ` [09/18] Vcompound: GFP_VFALLBACK debugging aid Christoph Lameter
2007-10-04 3:59 ` [10/18] Sparsemem: Use fallback for the memmap Christoph Lameter
2007-10-04 3:59 ` [11/18] Page allocator: Use a higher order allocation for the zone wait table Christoph Lameter
2007-10-04 3:59 ` [12/18] Wait: Allow bit_waitqueue to wait on a bit in a virtual compound page Christoph Lameter
2007-10-04 3:59 ` [13/18] x86_64: Allow fallback for the stack Christoph Lameter
2007-10-04 11:56 ` Andi Kleen
2007-10-04 12:08 ` Peter Zijlstra
2007-10-04 12:25 ` Andi Kleen
2007-10-04 12:30 ` Peter Zijlstra
2007-10-04 17:40 ` Christoph Lameter
2007-10-04 19:20 ` Christoph Lameter
2007-10-04 19:39 ` Rik van Riel
2007-10-04 21:20 ` Christoph Lameter
2007-10-07 7:35 ` Nick Piggin
2007-10-08 17:36 ` Christoph Lameter
2007-10-08 12:55 ` Nick Piggin
2007-10-09 18:39 ` Christoph Lameter
2007-10-09 8:46 ` Nick Piggin
2007-10-10 1:26 ` Christoph Lameter
2007-10-09 9:56 ` Nick Piggin
2007-10-10 3:36 ` where to get ZONE_MOVABLE pathces? Jacky(GuangXiang Lee)
2007-10-10 10:32 ` Mel Gorman
2007-10-06 18:53 ` Bill Davidsen [this message]
2007-10-04 3:59 ` [14/18] Configure stack size Christoph Lameter
2007-10-04 4:36 ` Arjan van de Ven
2007-10-04 4:43 ` David Miller, Arjan van de Ven
2007-10-04 19:34 ` Christoph Lameter
2007-10-04 9:11 ` Andi Kleen
2007-10-04 19:26 ` Christoph Lameter
2007-10-04 3:59 ` [15/18] Fallback for temporary order 2 allocation Christoph Lameter
2007-10-04 3:59 ` [16/18] Virtual Compound page allocation from interrupt context Christoph Lameter
2007-10-04 3:59 ` [17/18] Virtual compound page freeing in " Christoph Lameter
2007-10-04 3:59 ` [18/18] SLUB: Use fallback for table of callers/freers of a slab cache Christoph Lameter
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=4707D9B4.8020904@tmr.com \
--to=davidsen@tmr.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=travis@sgi.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;
as well as URLs for NNTP newsgroup(s).