Re: [PATCH] Port SquashFS to 2.6

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Mon, 21 July 2003 19:52:39 -0700, junkio@cox.net wrote:
> >>>>> "JE" == JörnEngel  <joern@wohnheim.fh-wedel.de> writes:
>
> JE> Depending on where and what you do,...
> 
> Well, isn't asking about address_space_operations.readpage
> specific enough?

Not for someone as lazy as me.  If you want to know for sure:
- Figure out all possible path leading to that function.
- Figure out all possible path called by that function.
- Sum up all the stack allocated variable size for both.
- Add the architecture-specific function call overhead, multiplied
  by the number of functions on both paths.

Now you have the stack consumption that you were not responsible for,
which depends on the architecture.  Substract that number from the
total stack size, which is also architecture-specific and you know how
much is left.  It is a lot of work and the hard part is finding all
the possible paths.  If you have a good idea how to automate that,
please tell me.  Else, we have to live with rules of thumb.

> JE> ... also depends a bit on the architecture.  s390 has
> JE> giant stacks because function call overhead is huge, ...
> 
> The discussion was about putting variables (or arrays or large
> structs) the kernel programmer defines on the stack, and I do
> not think architecture calling convention has much to do with
> this.
> 
> If an architecture has a big stack usage per call that is
> imposed by the ABI, and larger kernel stack is allocated
> compared to other architectures because of this reason,
> shouldn't there be about the same amount of usable space left
> for the kernel programs within the allocated per-process kernel
> stack space to use?  If that is not the case then the port to
> that particular architecture would not be optimal, wouldn't it?

You end up with all sorts of architecture dependent stuff when
allocating stack.  A long is 4 or 8 bytes, same for pointers, the
amount and size of saved registers differs, the size of the stack
differs, some architectures have a seperate interrupt stack.

If you look closely at the kernel, there is currently no way of
telling whether it contains stack overflows waiting to happen, or not.
We live with lots of hope and the comforting feeling that there were
not many stack overflows in the past.  I wish we had better tools, but
we don't.

Jörn

-- 
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories