Re: [2.6 patch] i386: always use 4k stacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 19 December 2005 02:34:29 +0100, Adrian Bunk wrote:
> On Mon, Dec 19, 2005 at 11:45:24AM +1100, Neil Brown wrote:
> > 
> > It's hard to *know* if it is a problem, but I am conscious that nfsd
> > adds measurably to stack depth for filesystem paths, and probably
> > isn't measured nearly as often.
> > It's true that 50 bytes out of 4K isn't a lot, but wastage that can be
> > avoided, should be avoided.
> 
> "make checkstack" tells that nfsd_vfs_write is below 100 bytes of stack 
> usage. So even calling 30 such functions would not get you above
> 3 kB stack usage.
> 
> It's also interesting that according to Jörn Engel's static analysis of 
> call paths in kernel 2.6.11 [1], the string "nfs" does occur in neither 
> any of the functions involved in call paths with > 2 kB stack usage, nor 
> in any recursive call paths.
> 
> It's OK to use some bytes from the stack, and you haven't yet convinced 
> me that the code you are responsible for is using too much stack.  ;-)

Well, my metrics show the worst non-recursive paths and recursions
only.  The case at hand is a relatively innocent path on its own, but
is stacked on top of one of the recursions.

Therefore, if my tool could make more sense of recursions and f.e. see
that raid over raid is unlikely, but nfsd over xfs over raid over
block is likely, nfsd would definitely show up.  Recursions are the
hard problem to worry about.

Don't blame Neil for my tool being stupid. :)

Jörn

-- 
Don't patch bad code, rewrite it.
-- Kernigham and Pike, according to Rusty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux