From: Arjan van de Ven <arjanv@redhat.com>
To: Tigran Aivazian <tigran@veritas.com>
Cc: Arjan van de Ven <arjanv@redhat.com>,
linux-kernel@vger.kernel.org,
Rik van Riel <riel@conectiva.com.br>
Subject: Re: [patch] larger kernel stack (8k->16k) per task
Date: Fri, 8 Feb 2002 11:09:30 -0500 [thread overview]
Message-ID: <20020208110930.C1429@devserv.devel.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0202081559240.1359-100000@einstein.homenet>
In-Reply-To: <Pine.LNX.4.33.0202081559240.1359-100000@einstein.homenet>; from tigran@veritas.com on Fri, Feb 08, 2002 at 04:06:35PM +0000
On Fri, Feb 08, 2002 at 04:06:35PM +0000, Tigran Aivazian wrote:
> Hi Arjan,
>
> > Also it's the wrong approach. The right approach (as done by Manfred and
> > David) is
> > to put "current" no longer on this stack just a pointer to current.
>
> You are saying that the right approach is to move "current" off the stack.
> The right approach to what? Surely not to saving kernel stack because
> "current" (being merely a struct task_struct) is not a major eater of the
> stack.
1.5Kb... that's quite a lot on 8Kb
> Those functions which declare 5-6k of local variables are (if
> there are still any left).
There are none. And if there are they are very easy to find and fix.
> Speaking of which, I will also answer Rik --
> the offenders (that "VERY VERY sick code" Arjan refers to) we found were
> in LKCD so it's been fixed ages ago.
LKCD is not part of the normal kernel, and in some parts could fall under
"VER VERY sick"; esp if they indeed use 6Kb stack.
> So, moving struct task_struct is irrelevant, really. Unless you meant
> something completely different and if so I look forward to your
Apparently you see stackoverflows with some code. Well, 1.5Kb (approx)
is some win there (although most of that is reserved for stack coloring).
If you need even more in your code (I assume you do otherwise you wouldn't
have done the work) then I really suggest you take a long hard look and fix
the obvious bugs or the design....
Greetings,
Arjan van de Ven
next prev parent reply other threads:[~2002-02-08 16:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-08 16:06 [patch] larger kernel stack (8k->16k) per task Tigran Aivazian
2002-02-08 16:09 ` Arjan van de Ven [this message]
2002-02-08 16:59 ` Tigran Aivazian
2002-02-08 16:57 ` Arjan van de Ven
2002-02-08 17:23 ` Arjan van de Ven
2002-02-08 18:16 ` Alan Cox
2002-02-08 18:29 ` Richard B. Johnson
2002-02-08 18:38 ` Arjan van de Ven
2002-02-08 20:54 ` Ingo Molnar
2002-02-08 18:15 ` Alan Cox
2002-02-08 20:22 ` Jes Sorensen
2002-02-08 21:12 ` Mike Fedyk
2002-02-09 7:17 ` george anzinger
-- strict thread matches above, loose matches on Subject: below --
2002-02-08 15:20 Tigran Aivazian
2002-02-08 15:36 ` Arjan van de Ven
2002-02-08 15:43 ` Rik van Riel
2002-02-08 15:52 ` Alan Cox
2002-02-08 20:08 ` Andrew Morton
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=20020208110930.C1429@devserv.devel.redhat.com \
--to=arjanv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=tigran@veritas.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