From owner-freebsd-current@FreeBSD.ORG Tue Apr 15 04:36:18 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A419106566B for ; Tue, 15 Apr 2008 04:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id F267F8FC2C for ; Tue, 15 Apr 2008 04:36:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 15 Apr 2008 05:58:40 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 613B62D6004; Mon, 14 Apr 2008 21:36:12 -0700 (PDT) Message-ID: <480430C0.8010601@elischer.org> Date: Mon, 14 Apr 2008 21:36:16 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Andrew Reilly References: <48002444.4030505@elischer.org> <20080412191300.E7693@fledge.watson.org> <20080412181601.GA14472@freebsd.org> <20080415034343.GB87024@duncan.reilly.home> In-Reply-To: <20080415034343.GB87024@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , Robert Watson , FreeBSD Current Subject: Re: stack hogs in kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 04:36:18 -0000 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, >