Re: stack hogs in kernel

On Sat, Apr 12, 2008 at 08:16:01PM +0200, Roman Divacky wrote:
> On Sat, Apr 12, 2008 at 07:14:21PM +0100, Robert Watson wrote:
> > 
> > On Fri, 11 Apr 2008, Julian Elischer wrote:
> > 
> > >0xc05667e3 kldstat [kernel]:				2100
> > >0xc07214f8 sendsig [kernel]:				1416
> > >0xc04fb426 ugenread [kernel]:				1200
> > >0xc070616b ipmi_smbios_identify [kernel]:		1136
> > >0xc050bd26 usbd_new_device [kernel]:			1128
> > >0xc0525a83 pfs_readlink [kernel]:			1092
> > >0xc04fb407 ugenwrite [kernel]:				1056
> > >0xc055ea33 prison_enforce_statfs [kernel]:		1044
> > 
> > This one, at least, is due to an issue Roman pointed out on hackers_at_ in the 
> > last 24 hours -- a MAXPATHLEN sized buffer on the stack.  Looks like 
> > pfs_readlink() has the same issue.
> 
> I plan to look at some of the MAXPATHLEN usage... I guess we can shave a few
> tens of KBs from the kernel (static size and runtime size).

Why are single-digit kilobytes of memory space interesting, in this
context?  Is the concern about L1 data cache footprint, for performance
reasons?  If that is the case, the MAXPATHLEN bufffer will only really
occupy the amount of cache actually touched.

I've long wondered about the seemingly fanatical stack size concern in
kernel space.  In other domains (where I have more experience) you can
get good performance benefits from the essentially free memory management
and good cache re-use that comes from putting as much into the
stack/call-frame as possible.

Just curious.

Cheers,

-- 
Andrew