Re: current state of the great stack overflow hunt

Roger Tsang wrote:
> I'd imagine allocating more structures from memory to save <<10% to
> support 4K stacks actually increases fragmentation and goes against
> the purpose of 4K stacks.
>   
Yeah, apart from moving the struct file in cfsd_read/cfsd_write all my 
changes have been focused around re-arranging the code to reduce stack 
space - with quite good results.

As I understand it one of the things newer kernels do is to avoid 
recursion in generic_make_request.  Looking at some of the backtraces I 
have seen this looks like a good thing, but it wouldn't cope with the 
last one - we have a call chain that looks like:

sys_close -> cfs_file_flush -> cfsd_write -> generic_file_writev -> 
(ext3/jbd stuff) -> generic_make_request -> (drbd stuf) -> (tcp stuff)

I haven't spent much time looking into how Linux I/O really works so I 
have no idea whether it would be possible for cfsd_write to somehow call 
generic_make_request instead of generic_file_writev, but in more recent 
kernels that would "fix" this case.

> Also according to this article (http://kerneltrap.org/8k_stacks) the
> base kernel with 4K stacks already runs into problems with some
> configurations - eg. nfs+xfs+raid.  It's not worth chasing drbd.
>   
As far as I know they're still pushing ahead with it though.
> There is something we can do and that is 64-bit OpenSSI.
>   
:-)



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