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
<dil...@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
:--
:pape...@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 majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
