From owner-freebsd-hackers Wed Mar 12 19:04:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA28961 for hackers-outgoing; Wed, 12 Mar 1997 19:04:58 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA28952 for ; Wed, 12 Mar 1997 19:04:54 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id DAA24989; Thu, 13 Mar 1997 03:04:12 GMT Date: Thu, 13 Mar 1997 12:04:12 +0900 (JST) From: Michael Hancock To: "David S. Miller" cc: ccsanady@nyx.pr.mcs.net, hackers@freebsd.org Subject: Re: Solaris TPC-C benchmarks (with Oracle) In-Reply-To: <199703130221.VAA21577@jenolan.caipgeneral> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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