Re: Stack usage

I have been thinking about consolidating rpcargs+rpcret structures for
instance and allocating from kmem cache.  It's more work.

Will making your recommended changes in just the CFS proc layer fix
this drbd + 4K stacks issue?

Roger

On Tue, Jan 13, 2009 at 2:20 PM, John Hughes <[email protected]> wrote:
> John Hughes wrote:
>>
>> One of the problems we have in current OpenSSI is excessive stack usage.
>>  This is often a problem when we use drbd for the root filesystem (cfs calls
>> drbd which calls the socket layer which... runs out of stack).
>>
>
> See bug
> https://sourceforge.net/tracker2/?func=detail&aid=1367582&group_id=32541&atid=405834
>
> One coding style in OpenSSI that leads to "excessive" stack usage is:
>
> some_cfs_func (...) {
>   if (for this node) {
>      do on this node;
>   }
>   else {
>       rpcargs args;
>       rpcret ret;
>       args = ...;
>       status = rpccall (...);
>       ...
>   }
> }
>
> The problem is that the space used by the rpc args and ret is allocated on
> the stack even on the path where the operation is local. This path is
> often (always?) deeper (especially when drbd is being used!).
>
> (It's a pity gcc couldn't be smarter about this!)
>
> A "solution" may be to rework the function to look something like:
>
> some_cfs_func (...) {
>   if (for this node) {
>      do on this node;
>   }
>   else {
>       status = some_cfs_func_remote ();
>   }
> }
>
> some_cfs_func_remote (...) {
>    rpcargs args;
>    rpcret ret;
>    args = ...;
>    status = rpccall (...);
>    ...
> }
>
> Now the local path doesn't get the rpc args on the stack.
>
> It's ugly though.
>
> (E.G. for cfs_proc_rename only 44 bytes are needed on the local path as
> against 472 bytes on the rpc path).
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> ssic-linux-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel
>
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword