From owner-freebsd-hackers Thu Jul 22 13:58:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C990714E6C for ; Thu, 22 Jul 1999 13:58:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA87639; Thu, 22 Jul 1999 13:56:42 -0700 (PDT) (envelope-from dillon) Date: Thu, 22 Jul 1999 13:56:42 -0700 (PDT) From: Matthew Dillon Message-Id: <199907222056.NAA87639@apollo.backplane.com> To: Papezik Milon Cc: hackers@FreeBSD.ORG Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c References: <37976C03.A4A797A7@pvt.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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