On Tue, 3 Feb 2004, Matthew Dillon wrote: > :... > :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > :robert_at_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_at_fledge.watson.org Senior Research Scientist, McAfee ResearchReceived on Tue Feb 03 2004 - 10:13:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:41 UTC