Date: Mon, 14 Apr 2008 21:36:16 -0700 From: Julian Elischer <julian@elischer.org> To: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> Cc: Roman Divacky <rdivacky@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>, FreeBSD Current <current@FreeBSD.org> Subject: Re: stack hogs in kernel Message-ID: <480430C0.8010601@elischer.org> In-Reply-To: <20080415034343.GB87024@duncan.reilly.home> References: <48002444.4030505@elischer.org> <20080412191300.E7693@fledge.watson.org> <20080412181601.GA14472@freebsd.org> <20080415034343.GB87024@duncan.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Reilly wrote: > 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@ 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. We used to have 1 page in the beginning, but that quickly went to 2. We now Have, I think, 4 (I should go look I guess.). But that was with the possibility of multiple interrupt frames all stacking on top of each other. Now that that has, been kept to a minimum we might be able to get to one or two again if we tried.. kernel stacks are a scarse resource.. they are not really swappable and are always present. > 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. That is an interesting point.. > > Just curious. > > Cheers, >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?480430C0.8010601>