Date: Thu, 13 Mar 2003 15:01:47 +0200 From: Petri Helenius <pete@he.iki.fi> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: mbuf cache Message-ID: <3E70813B.7040504@he.iki.fi> References: <0ded01c2e295$cbef0940$932a40c1@PHE> <20030304164449.A10136@unixdaemons.com> <0e1b01c2e29c$d1fefdc0$932a40c1@PHE> <20030304173809.A10373@unixdaemons.com> <0e2b01c2e2a3$96fd3b40$932a40c1@PHE> <20030304182133.A10561@unixdaemons.com> <0e3701c2e2a7$aaa2b180$932a40c1@PHE> <20030304190851.A10853@unixdaemons.com> <001201c2e2ee$54eedfb0$932a40c1@PHE> <20030307093736.A18611@unixdaemons.com> <008101c2e4ba$53d875a0$932a40c1@PHE> <3E68ECBF.E7648DE8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: >Ah. You are receiver livelocked. Try enabling polling; it will >help up to the first stall barrier (NETISR not getting a chance >to run protocol processing to completion because of interrupt >overhead); there are two other stall barriers after that, and >another in user space is possible depending on whether the >application layer is request/response. > > > Are you sure that polling would help even since the em driver is using interrupt regulation by default? It might solve the livelock but it does probably not increase the performance of the mbuf allocator? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E70813B.7040504>