Port SquashFS to 2.6

JE> Depending on where and what you do,...

Well, isn't asking about address_space_operations.readpage specific enough?

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?

Not necessarily. It's quite possible (likely even) that one architecture might have N bytes overhead per call, and is allowed a 4K stack, and some other architecture has (N+30%) overhead, so 4K isn't enough - 5K is needed. However, other considerations cause a whole-page allocation, so instead of allocating 5K, it goes to 8K, with a 3K wastage....

So yes, you can end up with suboptimal results.

And even worse, for short call chains, 4.1k would be enough, but for long ones, you need up to 5.2k. How much is too much? We don't know and it depends, so make a pessimistic guess.

Joern

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.

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