All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Linda Walsh <lkml@tlinx.org>
Cc: Paulo Marques <pmarques@grupopie.com>,
	Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Save 320K on production machines?
Date: Fri, 31 Mar 2006 11:43:15 +0200	[thread overview]
Message-ID: <20060331094315.GB3893@stusta.de> (raw)
In-Reply-To: <442C4ECF.3080505@tlinx.org>

On Thu, Mar 30, 2006 at 01:34:07PM -0800, Linda Walsh wrote:
>...
> If I "doubled" my stack back to 8K, that would lower the "random
> probability" of hitting a stack limit, but right now, it seems like
> amount of stack "needed" is nearly guesswork.  Sigh.  Having my
> kernel fairly static and minimalistic (no unused modules; no loadable
> modules, etc) I might only "need" 3K.

Things like unused modules or loadable module support should have more 
or less zero impact on stack usage.

> 1) It would be nice if a "stack usage" option could be turned on
> that would do some sort of run-time bounds checking that could
> display the max-stack used "so far" in "/proc".

The -rt kernel contains something like this.

> 2) How difficult would it be to place kernel stack in a "pageable" pool 
> where the limit of valid data in a 4K page is only 3.5K - then
> when a kernel routine tries to exceed the stack boundary, it takes a
> page fault where a "note" could be logged that more stack was "needed",
> then automatically map another 4K page into the stack and return to
> interrupted routine.
> 
> It sounds a bit strange -- the kernel having to call another part of
> the kernel to handle a pagefault within the kernel, but perhaps there
> could be another level of "partitioning" w/in kernel space that would
> allow the non-paging part of the kernel to be paged in/out in a similar
> way to user code. 
>...

This has been discussed to death, and the consensus was that code 
resulting in a too high stack usage should be fixed.

If you find any stack problems with 4k stacks and the automatically 
enabled unit-at-a-time when using gcc 4.x in kernel 2.6.16-mm2, please 
send a bug report.

Regarding unit-at-a-time with gcc 3.x, it works most time for most 
people, but it's completely unsupported. If you want to use 
unit-at-a-time on i386, please use gcc 4.x.

> -l

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2006-03-31  9:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-26  8:31 Save 320K on production machines? Linda Walsh
2006-03-26  9:24 ` Jan Engelhardt
2006-03-26 10:06   ` Adrian Bunk
2006-03-27 10:22     ` Linda Walsh
2006-03-27 11:36       ` Paulo Marques
2006-03-30 21:34         ` Linda Walsh
2006-03-31  9:43           ` Adrian Bunk [this message]
2006-03-31  9:48           ` Jörn Engel
2006-03-26 10:39 ` Andre Tomt
2006-03-27 10:05   ` Linda Walsh
2006-03-28 14:29     ` Jan Engelhardt

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=20060331094315.GB3893@stusta.de \
    --to=bunk@stusta.de \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@tlinx.org \
    --cc=pmarques@grupopie.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.