Date: Thu, 13 Mar 1997 12:04:12 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: "David S. Miller" <davem@jenolan.rutgers.edu> Cc: ccsanady@nyx.pr.mcs.net, hackers@freebsd.org Subject: Re: Solaris TPC-C benchmarks (with Oracle) Message-ID: <Pine.SV4.3.95.970313115910.24884A-100000@parkplace.cet.co.jp> In-Reply-To: <199703130221.VAA21577@jenolan.caipgeneral>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Mar 1997, David S. Miller wrote: > No one has quantified that pbufs can be made to scale on SMP, it may > (and I think it will) have the same scalability problems that SLAB > allocators can have. At a minimum you'd have to grab a per device > lock to keep track of the device pbuf pool properly, since any of the > networking code can call upon the code which needs to acquire this > lock you're probably going to need to make it a sleeping lock to get > decent performance. Guess what? Then you need to implement what > Solaris does which is allow interrupt handlers to sleep, in order for > it to work at all. Kernel threads. > I'd suggest fixing the TCP timers first, they are a much larger > scalability problem than the buffering in BSD. (IRIX scales to 2,000 > connections per second, thats real connections, not some bogus Zeus > benchmark exploiting http connection reuse features etc., and they're > still using mbufs) Then go to the time wait problem (much harder to > solve than the timers, but less painful to fix than redoing the > buffering), then fix select(), then think about pbufs. Make you wonder if mbufs are even a problem. The chains don't ever become long chains do they? Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970313115910.24884A-100000>