Date: Wed, 7 May 2003 15:56:57 +0200
From: =?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: top stack (l)users for 2.5.69
Message-ID: <20030507135657.GC18177@wohnheim.fh-wedel.de>
References: <20030507132024.GB18177@wohnheim.fh-wedel.de> <Pine.LNX.4.53.0305070933450.11740@chaos>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Pine.LNX.4.53.0305070933450.11740@chaos>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1439
Lines: 34

On Wed, 7 May 2003 09:45:13 -0400, Richard B. Johnson wrote:
> 
> You know (I hope) that allocating stuff on the stack is not
> "bad". In fact, it's the quickest way to allocate data that
> will automatically go away when the function returns. One
> just subtracts a value from the stack-pointer and you have
> the data area. I sure hope that these temporary allocations
> are not being replaced with kmalloc()/kfree(). If so, the
> code is badly broken and you are eating my CPU cycles for
> nothing.

Agreed, partially. There is the current issue of the kernel stack
being just 8k in size and no decent mechanism in place to detect a
stack overflow. And there is (arguably) the future issue of the kernel
stack shrinking to 4k.

Stuff like intermezzo will break with 4k, no discussion about that.
Other stuff may or may not work. What I'm trying to do is pave the way
to shrink the kernel stack during 2.7 sometime.

If there is large agreement that the kernel stack should not shrink,
I'll stop this effort any day. But so far, I am under the impression
that the agreement is to do the shink. Am I wrong?

J?rn

-- 
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/