public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linda Walsh <lkml@tlinx.org>
To: Paulo Marques <pmarques@grupopie.com>
Cc: Adrian Bunk <bunk@stusta.de>,
	Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Save 320K on production machines?
Date: Thu, 30 Mar 2006 13:34:07 -0800	[thread overview]
Message-ID: <442C4ECF.3080505@tlinx.org> (raw)
In-Reply-To: <4427CE4D.5010109@grupopie.com>

Paulo Marques wrote:
> AFAICR, the problem with gcc3 and unit-at-a-time was stack usage with 
> local variables on automatically inlined functions.
>
> For instance, if function A called B and after B returned called C, 
> both local variables of B and C would be given a reserved space on the 
> stack during the execution of A if both functions were automatically 
> inlined. So the space needed now was A+B+C whereas before was Max(A+B, 
> A+C).
>
Hmmm...that at least makes some sense for disabling it, but jeez,
this stack "thing" is such an "unknown quantity".  It would be
"nice" if we had some clue about how much stack our systems actually
use -- I'm using a 4K stack size and system has been rock-solid
stable since around release of 2.15.2. 

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.

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".

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. 

I have *no clue*, if it is the same idea, but the NT kernel has *parts*
of the kernel marked swappable by default.  If one wants to lock all of
the kernel in memory, there is a flag that can be set in the registry
 to disable paging the "Executive".  Could that be applicable in
Linux?

-l



  reply	other threads:[~2006-03-30 21:34 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 [this message]
2006-03-31  9:43           ` Adrian Bunk
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=442C4ECF.3080505@tlinx.org \
    --to=lkml@tlinx.org \
    --cc=bunk@stusta.de \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox