Date: Tue, 3 Feb 2004 14:10:32 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@freebsd.org Subject: Re: Coalescing pipe allocation Message-ID: <Pine.NEB.3.96L.1040203140842.79056J-100000@fledge.watson.org> In-Reply-To: <200402031908.i13J8BAP003708@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Feb 2004, Matthew Dillon wrote: > :... > :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > :robert@fledge.watson.org Senior Research Scientist, McAfee Research > > It seems to me that realizing the lion's share of the benefit requires > only that you cache the KVM reservation for a pipe buffer, and that > you perhaps separately cache pipe meta data structures. I think > you would only get a smidgen more performance by caching the entire > pipe pair, so it seems a bit overkill to do that. By my quick read > it > looks like it would be trivial to create a small per-cpu (UMA based > for > you guys, globaldata based for me) cache. A hysteresis of 4 ought > to > be sufficient. Sounds like we agree (see earlier e-mails). However, I wanted to get the structural change to combine pipes into a single object done first, and settled. However, the current pipe model allows for a small number of "big pipes" and a larger number of "small pipes", with a fall-back from big to small pipes when you run out of big pipes (pretty quickly if you have a parallel build going on). Deferring the buffer allocation until it's needed helps conserve big pipes for where they are actually used, which will give you a benefit beyond amortizing the cost of buffer allocation. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040203140842.79056J-100000>