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,

_______________________________________________ mailing list
To unsubscribe, send any mail to ""