On Wednesday 10 October 2007 11:26, Christoph Lameter wrote:
> On Tue, 9 Oct 2007, Nick Piggin wrote:
> > > We already use 32k stacks on IA64. So the memory argument fail there.
> >
> > I'm talking about generic code.
>
> The stack size is set in arch code not in generic code.
Generic code must as
On Tue, 9 Oct 2007, Nick Piggin wrote:
> > We already use 32k stacks on IA64. So the memory argument fail there.
>
> I'm talking about generic code.
The stack size is set in arch code not in generic code.
> > > The solution has until now always been to fix the problems so they don't
> > > use s
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!
> >
> > Increas
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
> threa
On Tuesday 09 October 2007 03:36, Christoph Lameter wrote:
> On Sun, 7 Oct 2007, Nick Piggin wrote:
> > > The problem can become non-rare on special low memory machines doing
> > > wild swapping things though.
> >
> > But only your huge systems will be using huge stacks?
>
> I have no idea who else
On Sun, 7 Oct 2007, Nick Piggin wrote:
> > The problem can become non-rare on special low memory machines doing wild
> > swapping things though.
>
> But only your huge systems will be using huge stacks?
I have no idea who else would be using such a feature. Relaxing the tight
memory restriction
On Friday 05 October 2007 07:20, Christoph Lameter wrote:
> On Thu, 4 Oct 2007, Rik van Riel wrote:
> > > 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 ta
Rik van Riel wrote:
On Thu, 4 Oct 2007 12:20:50 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> 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 po
On Thu, 4 Oct 2007, Rik van Riel wrote:
> > 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
On Thu, 4 Oct 2007 12:20:50 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> 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
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.
> Is there any evidence this is more common now than it used to be?
It will be mo
On Thu, 4 Oct 2007, Andi Kleen wrote:
> > The order-1 allocation failures where GFP_ATOMIC, because SLUB uses !0
> > order for everything.
>
> slub is wrong then. Can it be fixed?
SLUB in mm kernels was using higher order allocations for some slabs
for the last 6 months or so. Not true for upst
On Thu, 2007-10-04 at 14:25 +0200, Andi Kleen wrote:
> > The order-1 allocation failures where GFP_ATOMIC, because SLUB uses !0
> > order for everything.
>
> slub is wrong then. Can it be fixed?
I think mainline slub doesn't do this, just -mm.
See DEFAULT_MAX_ORDER in mm/slub.c
> > Kernel stack
> The order-1 allocation failures where GFP_ATOMIC, because SLUB uses !0
> order for everything.
slub is wrong then. Can it be fixed?
> Kernel stack allocation is GFP_KERNEL I presume.
Of course.
> Also, I use 4k stacks on all my machines.
You don't have any x86-64 machines?
-Andi
-
To unsu
On Thu, 2007-10-04 at 13:56 +0200, Andi Kleen wrote:
> On Thursday 04 October 2007 05:59:48 Christoph Lameter wrote:
> > Peter Zijlstra has recently demonstrated that we can have order 1 allocation
> > failures under memory pressure with small memory configurations. The
> > x86_64 stack has a size
On Thursday 04 October 2007 05:59:48 Christoph Lameter wrote:
> Peter Zijlstra has recently demonstrated that we can have order 1 allocation
> failures under memory pressure with small memory configurations. The
> x86_64 stack has a size of 8k and thus requires a order 1 allocation.
We've known fo
Peter Zijlstra has recently demonstrated that we can have order 1 allocation
failures under memory pressure with small memory configurations. The
x86_64 stack has a size of 8k and thus requires a order 1 allocation.
This patch adds a virtual fallback capability for the stack. The system may
contin
17 matches
Mail list logo
