All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Lameter <clameter@sgi.com>
Cc: Rik van Riel <riel@redhat.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: Tue, 9 Oct 2007 18:46:22 +1000	[thread overview]
Message-ID: <200710091846.22796.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0710091138250.32162@schroedinger.engr.sgi.com>

On Wednesday 10 October 2007 04:39, Christoph Lameter wrote:
> On Mon, 8 Oct 2007, Nick Piggin wrote:
> > The tight memory restrictions on stack usage do not come about because
> > of the difficulty in increasing the stack size :) It is because we want
> > to keep stack sizes small!
> >
> > Increasing the stack size 4K uses another 4MB of memory for every 1000
> > threads you have, right?
> >
> > It would take a lot of good reason to move away from the general
> > direction we've been taking over the past years that 4/8K stacks are a
> > good idea for regular 32 and 64 bit builds in general.
>
> We already use 32k stacks on IA64. So the memory argument fail there.

I'm talking about generic code.


> > > I have some concerns about the medium NUMA systems (a few dozen of
> > > nodes) also running out of stack since more data is placed on the stack
> > > through the policy layer and since we may end up with a couple of
> > > stacked filesystems. Most of the current NUMA systems on x86_64 are
> > > basically two nodes on one motherboard. The use of NUMA controls is
> > > likely limited there and the complexity of the filesystems is also not
> > > high.
> >
> > The solution has until now always been to fix the problems so they don't
> > use so much stack. Maybe a bigger stack is OK for you for 1024+ CPU
> > systems, but I don't think you'd be able to make that assumption for most
> > normal systems.
>
> Yes that is why I made the stack size configurable.

Fine. I just don't see why you need this fallback.

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Lameter <clameter@sgi.com>
Cc: Rik van Riel <riel@redhat.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: Tue, 9 Oct 2007 18:46:22 +1000	[thread overview]
Message-ID: <200710091846.22796.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0710091138250.32162@schroedinger.engr.sgi.com>

On Wednesday 10 October 2007 04:39, Christoph Lameter wrote:
> On Mon, 8 Oct 2007, Nick Piggin wrote:
> > The tight memory restrictions on stack usage do not come about because
> > of the difficulty in increasing the stack size :) It is because we want
> > to keep stack sizes small!
> >
> > Increasing the stack size 4K uses another 4MB of memory for every 1000
> > threads you have, right?
> >
> > It would take a lot of good reason to move away from the general
> > direction we've been taking over the past years that 4/8K stacks are a
> > good idea for regular 32 and 64 bit builds in general.
>
> We already use 32k stacks on IA64. So the memory argument fail there.

I'm talking about generic code.


> > > I have some concerns about the medium NUMA systems (a few dozen of
> > > nodes) also running out of stack since more data is placed on the stack
> > > through the policy layer and since we may end up with a couple of
> > > stacked filesystems. Most of the current NUMA systems on x86_64 are
> > > basically two nodes on one motherboard. The use of NUMA controls is
> > > likely limited there and the complexity of the filesystems is also not
> > > high.
> >
> > The solution has until now always been to fix the problems so they don't
> > use so much stack. Maybe a bigger stack is OK for you for 1024+ CPU
> > systems, but I don't think you'd be able to make that assumption for most
> > normal systems.
>
> Yes that is why I made the stack size configurable.

Fine. I just don't see why you need this fallback.

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

  reply	other threads:[~2007-10-10  1:18 UTC|newest]

Thread overview: 85+ 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 ` Christoph Lameter
2007-10-04  3:59 ` [01/18] vmalloc: clean up page array indexing Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [02/18] vunmap: return page array passed on vmap() Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [03/18] vmalloc_address(): Determine vmalloc address from page struct Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [04/18] Vcompound: Smart up virt_to_head_page() Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [05/18] Page flags: Add PageVcompound() Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [06/18] Vcompound: Update page address determination Christoph Lameter
2007-10-04  3:59   ` 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   ` Christoph Lameter
2007-10-13 16:46   ` Compiling kernel 2.6.23.1 HELP animesh saxena
2007-10-13 17:12     ` Willy Tarreau
2007-10-14  2:35     ` Kristoffer Ericson
2007-10-04  3:59 ` [08/18] GFP_VFALLBACK: Allow fallback of compound pages to virtual mappings Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [09/18] Vcompound: GFP_VFALLBACK debugging aid Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [10/18] Sparsemem: Use fallback for the memmap Christoph Lameter
2007-10-04  3:59   ` 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   ` 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   ` Christoph Lameter
2007-10-04  3:59 ` [13/18] x86_64: Allow fallback for the stack Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04 11:56   ` Andi Kleen
2007-10-04 11:56     ` Andi Kleen
2007-10-04 12:08     ` Peter Zijlstra
2007-10-04 12:08       ` Peter Zijlstra
2007-10-04 12:25       ` Andi Kleen
2007-10-04 12:25         ` Andi Kleen
2007-10-04 12:30         ` Peter Zijlstra
2007-10-04 12:30           ` Peter Zijlstra
2007-10-04 17:40         ` Christoph Lameter
2007-10-04 17:40           ` Christoph Lameter
2007-10-04 19:20     ` Christoph Lameter
2007-10-04 19:20       ` Christoph Lameter
2007-10-04 19:39       ` Rik van Riel
2007-10-04 19:39         ` Rik van Riel
2007-10-04 21:20         ` Christoph Lameter
2007-10-04 21:20           ` Christoph Lameter
2007-10-07  7:35           ` Nick Piggin
2007-10-07  7:35             ` Nick Piggin
2007-10-08 17:36             ` Christoph Lameter
2007-10-08 17:36               ` Christoph Lameter
2007-10-08 12:55               ` Nick Piggin
2007-10-08 12:55                 ` Nick Piggin
2007-10-09 18:39                 ` Christoph Lameter
2007-10-09 18:39                   ` Christoph Lameter
2007-10-09  8:46                   ` Nick Piggin [this message]
2007-10-09  8:46                     ` Nick Piggin
2007-10-10  1:26                     ` Christoph Lameter
2007-10-10  1:26                       ` Christoph Lameter
2007-10-09  9:56                       ` Nick Piggin
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         ` [13/18] x86_64: Allow fallback for the stack Bill Davidsen
2007-10-06 18:53           ` Bill Davidsen
2007-10-04  3:59 ` [14/18] Configure stack size Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  4:36   ` Arjan van de Ven
2007-10-04  4:36     ` Arjan van de Ven
2007-10-04  4:43     ` David Miller
2007-10-04  4:43       ` David Miller, Arjan van de Ven
2007-10-04 19:34       ` Christoph Lameter
2007-10-04 19:34         ` Christoph Lameter
2007-10-04  9:11   ` Andi Kleen
2007-10-04  9:11     ` Andi Kleen
2007-10-04 19:26     ` Christoph Lameter
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   ` Christoph Lameter
2007-10-04  3:59 ` [16/18] Virtual Compound page allocation from interrupt context Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [17/18] Virtual compound page freeing in " Christoph Lameter
2007-10-04  3:59   ` Christoph Lameter
2007-10-04  3:59 ` [18/18] SLUB: Use fallback for table of callers/freers of a slab cache Christoph Lameter
2007-10-04  3:59   ` 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=200710091846.22796.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.