Date: Wed, 12 Mar 1997 22:13:34 -0500 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: michaelh@cet.co.jp Cc: ccsanady@nyx.pr.mcs.net, hackers@freebsd.org Subject: Re: Solaris TPC-C benchmarks (with Oracle) Message-ID: <199703130313.WAA21644@jenolan.caipgeneral> In-Reply-To: <Pine.SV4.3.95.970313115910.24884A-100000@parkplace.cet.co.jp> (message from Michael Hancock on Thu, 13 Mar 1997 12:04:12 %2B0900 (JST))
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Thu, 13 Mar 1997 12:04:12 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> 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. Not exactly, interrupt threads, which are kernel threads in disguise. You have to make these threads lighter than real kernel threads or else performance will suffer, and this is precisely what Solaris does, a light weight irq thread is preallocated for each interrupt priority level plus a few extra just to be safe. Make you wonder if mbufs are even a problem. The chains don't ever become long chains do they? Perhaps for ethernet etc. chain length is not an issue that often, but for FDDI, gigabit, and any other large MTU'd interface type it is a big issue. But however for most of them you're silly if you aren't page flipping on there. If anything, mbuf chaining introduces a significant portion of the conditionalized code all over the input processing, this in and of itself would justify the change I think. (imagine how light the code would be if every m_pullup() just disappeared? ;-) Regardless of whether the depth of the chains ever get large, the fact remains is that the chaining does exist and this in and of itself makes csum_copy difficult to implement efficiently as it must allot for this case in all runs. I hate to say it, but one win from the Solaris/mentat etc. streams stacks is that they are using contiguous buffers nearly all the time and thus their csum_copy is a piece of cake to make blazingly fast, in fact I believe the solaris stack guarentees that what csum_copy sees is not only nicely aligned but the buffer is always some multiple of 2 bytes. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703130313.WAA21644>