From owner-freebsd-hackers Thu Jul 22 14:56:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from users.anet-stl.com (users.anet-stl.com [209.145.150.20]) by hub.freebsd.org (Postfix) with ESMTP id 6101114F29 for ; Thu, 22 Jul 1999 14:56:46 -0700 (PDT) (envelope-from doogie@anet-stl.com) Received: from x ([209.145.151.138]) by users.anet-stl.com (8.9.3/8.8.5) with SMTP id QAA90574; Thu, 22 Jul 1999 16:53:06 -0500 (CDT) From: "Jason Young" To: "Matthew Dillon" , "Papezik Milon" Cc: Subject: RE: Squid - a bug in src/sys/kern/uipc_socket.c Date: Thu, 22 Jul 1999 16:43:31 -0500 Message-ID: <000501bed48b$3de34600$8a9791d1@y> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <199907222056.NAA87639@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It's been committed before, and broke many things (X and CVSup come to mind). I have it compiled in locally on a few machines but it's definitely not suitable for general distribution until a solution is found that doesn't break applications. Jason Young accessUS Chief Network Engineer > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of > Matthew Dillon > Sent: Thursday, July 22, 1999 3:57 PM > To: Papezik Milon > Cc: hackers@FreeBSD.ORG > Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c > > > This isn't really a bug since this is a TCP connection. > TCP makes > no guarentees that atomic writes will show up as atomic > reads, and > the squid code shouldn't be making that assumption. > > On the otherhand, the proposed fix appears to be an > excellent performance > optimization. It is basically only turning 'atomic' on > for relatively > small writes, which should be a win for a receiver > whether over a > localhost connection or a real network. I can't > imagine that it would > cause a performance loss in any other situation -- it > might result in > a slightly smaller-then-full-sized TCP packet > occassionally in a stream > but that's about it. > > I think committing this would be beneficial. Would > someone w/ commit > privs care to review and then commit this bit? > > -Matt > Matthew Dillon > > > :Hi, > : > :please don't kill me if it's "well known issue": > : > :I've found that there is a report on Squid site, which > :describes a problem with FreeBSD IPC and includes suggested fix. > :I verified that this suggested fix is not included in 3.2-RELEASE. > : > :I wonder, if it is really a bug, as I cannot find it in PR > database. > : > :Could someone please comment on this report/bug/suggested fix > :and if/when the fix could/will be submited? > : > :original URL: > :http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2 > : > : Thanks in advance, > : Milon > :-- > :papezik@pvt.net > : > : > :------------ bug report and suggested fix --------- > :mbuf size > : > :We noticed an odd thing with some of Squid's interprocess > communication. > :Often, output from the dnsserver processes would NOT be read in one > :chunk. With full debugging, it looks like this: > : > :1998/04/02 15:18:48| comm_select: FD 46 ready for reading > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from > DNS ID 2 (100 > :bytes) > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply > :....other processing occurs... > :1998/04/02 15:18:48| comm_select: FD 46 ready for reading > :1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9 > :bytes) > :1998/04/02 15:18:48| ipcache_parsebuffer: parsing: > :$name www.karup.com > :$h_name www.karup.inter.net > :$h_len 4 > :$ipcount 2 > :38.15.68.128 > :38.15.67.128 > :$ttl 2348 > :$end > : > :Interestingly, it is very common to get only 100 bytes on the first > :read. When two read() calls are required, this adds > additional latency > :to the overall request. On our caches running Digital > Unix, the median > :dnsserver response time was measured at 0.01 seconds. On > our FreeBSD > :cache, however, the median latency was 0.10 seconds. > : > :Here is a simple patch to fix the bug: > : > :=================================================================== > :RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v > :retrieving revision 1.40 > :retrieving revision 1.41 > :diff -p -u -r1.40 -r1.41 > :--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40 > :+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06 > 19:27:14 > :1.41 > :@@ -31,7 +31,7 @@ > : * SUCH DAMAGE. > : * > : * @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94 > :- * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $ > :+ * $Id: FAQ.sgml,v 1.75 1999/07/06 16:07:36 wessels Exp $ > : */ > : > : #include > :@@ -491,6 +491,7 @@ restart: > : mlen = MCLBYTES; > : len = min(min(mlen, resid), space); > : } else { > :+ atomic = 1; > : nopages: > : len = min(min(mlen, resid), space); > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message