[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a8748490707121925w5fb22c0o61068f06d66d5845@mail.gmail.com>
Date: Fri, 13 Jul 2007 04:25:56 +0200
From: "Jesper Juhl" <jesper.juhl@...il.com>
To: "Jeremy Fitzhardinge" <jeremy@...p.org>
Cc: "Ray Lee" <ray-lk@...rabbit.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"William Lee Irwin III" <wli@...omorphy.com>
Subject: Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
On 13/07/07, Jeremy Fitzhardinge <jeremy@...p.org> wrote:
> Jesper Juhl wrote:
> > If, on the other hand, we consider 4K stacks to be the superior
> > solution, then we should work to get all code fixed to be able to
> > handle it so that it's actually something distros will start to enable
> > so that we can eventually get rid of the 8K stack option alltogether.
> > Making 4K stacks default and no longer a debug option is just the
> > first step in that direction.
>
> First step is to apply wli's patch which makes separate interrupt stacks
> orthogonal to the 4K stack option.
>
Yes and no. If that will get things moving in the direction of
getting rid of the stack size as a config option, then I'm all for it.
But on the other hand it is my personal opinion that this is an area
where we should just make up our minds as to whether we want 4K or 8K
stacks and whether we want interrupt stacks or not, and then not have
it configurable at all. I believe the goal is 4K stacks + interrupt
stacks, so let's just aim for that and get rid of the configurability
of the damn thing - make a choice, make it work, make it be that
that's what we use and rid ourselves of the alternatives...
--
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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/
Powered by blists - more mailing lists