Date: Thu, 22 Jul 1999 14:58:36 -0700 (PDT) From: Jaye Mathisen <mrcpu@internetcds.com> To: Jason Young <doogie@anet-stl.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Papezik Milon <papezik@pvt.net>, hackers@FreeBSD.ORG Subject: RE: Squid - a bug in src/sys/kern/uipc_socket.c Message-ID: <Pine.BSF.4.10.9907221458210.16718-100000@schizo.cdsnet.net> In-Reply-To: <000501bed48b$3de34600$8a9791d1@y>
next in thread | previous in thread | raw e-mail | index | archive | help
Maybe it could be made a sysctl knob... On Thu, 22 Jul 1999, Jason Young wrote: > > 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 > > <dillon@backplane.com> > > > > :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 <sys/param.h> > > :@@ -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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9907221458210.16718-100000>