Re: stack hogs in kernel

Julian Elischer wrote:
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

Last time I checked (when we first went to gcc 4.x) we are still at
2 - 4k stack pages.

R

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,


_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"



--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: stack hogs in kernel
    ... tens of KBs from the kernel. ... Is the concern about L1 data cache footprint, ... kernel stacks are a scarse resource.. ... get good performance benefits from the essentially free memory management ...
    (freebsd-current)
  • [Full-disclosure] PHRACK 64: ATTACKING THE CORE
    ... - The Slab Allocator ... - Slab overflow exploiting: ... - Forcing a kernel path to sleep ... - Stack Frame Flow Recovery ...
    (Full-Disclosure)
  • Re: Cached memory never gets released
    ... Stock linux 2.4.26 kernel. ... Due to flash bug 3M of memory gets lost due to font memory getting lost ... The output of "free" cache number steadily grows. ... longer to exhaust all of system memory with the cache. ...
    (Linux-Kernel)
  • Re: Interrupt context...
    ... > gone through most of the posts on interrupt in usenet. ... > kernel stack and ISR is executed. ... More may be saved depending on the architecture. ... Here the kernel have assembler code to save all general ...
    (comp.os.linux.development.system)
  • Re: Why is GForth-ITC fast?
    ... The kernel and the application code (so-called "userland") do not run ... That jump entails a "stack switch", ... the only thing is I guess if you want to do syscalls ...
    (comp.lang.forth)