[ ssic-linux-Bugs-1367582 ] crashes with 4KSTACKS

Bugs item #1367582, was opened at 2005-11-27 11:02
Message generated for change (Comment added) made by rogertsang
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=405834&aid=1367582&group_id=32541

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Booting / init
Group: v1.9.1
Status: Closed
Resolution: Fixed
Priority: 1
Private: No
Submitted By: lmc (catucci)
Assigned to: Nobody/Anonymous (nobody)
Summary: crashes with 4KSTACKS 

Initial Comment:
The default kernel for 1.9, compiled with
CONFIG_4KSTACKS does crash after havin been used for a
while. Please consider not setting CONFIG_4KSTACKS as a
default.

----------------------------------------------------------------------

>Comment By: Roger Tsang (rogertsang)
Date: 2009-01-20 21:14

Message:
See the following:
[ ssic-linux-Patches-2525429 ] help get backtraces of (near) stack
overflow situations
[ ssic-linux-Patches-2525436 ] reduce cluster/sync.h stack usage
[ ssic-linux-Patches-2525437 ] reduce stack usage in do_ssi_write
[ ssic-linux-Patches-2525441 ] reduce stack usage in local CFS path

----------------------------------------------------------------------

Comment By: John Hughes (hughesj)
Date: 2009-01-13 09:12

Message:
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!).

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.

(E.G. for cfs_proc_rename only 44 bytes are needed on the local path as
against 472 bytes on the rpc path).


----------------------------------------------------------------------

Comment By: Roger Tsang (rogertsang)
Date: 2008-01-01 20:13

Message:
Logged In: YES 
user_id=1246761
Originator: NO

OPENSSI-2-0-0-PRE2 no longer has CONFIG_4KSTACKS as default.

----------------------------------------------------------------------

Comment By: Roger Tsang (rogertsang)
Date: 2007-08-12 20:21

Message:
Logged In: YES 
user_id=1246761
Originator: NO

lowered priority; not a show stopper.

----------------------------------------------------------------------

Comment By: John Hughes (hughesj)
Date: 2007-08-07 06:38

Message:
Logged In: YES 
user_id=166336
Originator: NO

For me it always crashes with 4Kstacks if I try to use drbd.  Non-drbd
configs work ok with 4kstacks

----------------------------------------------------------------------

Comment By: lmc (catucci)
Date: 2005-11-27 20:43

Message:
Logged In: YES 
user_id=1190855

Sorry, I have no direct evidence, save from my cluster being
up and running since I compiled my own kernel, with 4kstaks
disabled, after some days of sudden crashes after standard
install... at first I tried to collect evidence via
netconsole,  applied the netconsole patch for sis900 and
experienced the non-initnode netconsole crashes; thereafter
I compiled a non-4kstaks kernel, and the crashes stopped.

----------------------------------------------------------------------

Comment By: Roger Tsang (rogertsang)
Date: 2005-11-27 20:34

Message:
Logged In: YES 
user_id=1246761

Can you post any information that will clearly explain how
the crash is directly related to CONFIG_4KSTACKS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=405834&aid=1367582&group_id=32541

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