From owner-freebsd-net Sat Jun 29 16:11:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12AB437B400; Sat, 29 Jun 2002 16:11:22 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA1C43E1F; Sat, 29 Jun 2002 16:11:20 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 97FB4AE25A; Sat, 29 Jun 2002 16:11:20 -0700 (PDT) Date: Sat, 29 Jun 2002 16:11:20 -0700 From: Alfred Perlstein To: Bosko Milekic Cc: Jeffrey Hsu , Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629231120.GO97638@elvis.mu.org> References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> <20020629190844.A54115@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020629190844.A54115@unixdaemons.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bosko Milekic [020629 16:09] wrote: > > On Sat, Jun 29, 2002 at 03:46:31PM -0700, Jeffrey Hsu wrote: > > So, what you want is something like a > > MGETHCL(m, how, type) > > MHCLFREE(m) > > interface which first looks in a combined freelist before the individual > > mbuf and cluster freelists. I think it's a good idea. > > I would prefer to see an interface that just grabs both a cluster and > an mbuf from their respective per-CPU caches (in -CURRENT) while only > grabbing the lock once, if at all this is that important to you. [*] > > In -CURRENT right now, clusters and mbufs are allocated from > different per-CPU cache lists but they _share_ per-CPU > locks, therefore this is entirely do-able. Having yet another cache > that holds linked cluster + mbufs would really complicate allocations. > > [*] Admittedly, Alfred was pushing for exactly this not long ago, but > I just didn't feel like doing it because I felt that there are better > things to worry about than a little unlock + relock, when we're just > dropping and re-acquiring the exact same lock, I don't see it as too > big of a deal. However, I'm really not sure as to how smart > architectures like Intel are with bus-locked instructions and data > cache use. If they're stupid about it (i.e., if they don't look at > caches during a bus-locked cycle), then it could be worth it to avoid > that extra unlock/relock between allocations. If they're fairly smart > about it, it's really not worth it. > > Also, I should mention that in his original message, Luigi mentions > that MGETHDR and MCLGET are rather long macros, but in -CURRENT they > are functions so there is not really much added code cache pollution. Heh... :) If the pool is per-device-softc then it doesn't need locks and will be a lot more efficient than even grabbing from the per cpu pool. Also, (/me does a little dance) TOLD YOU SO ABOUT THE ALLOCATION CODE! hah! :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message