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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Matthew Dillon
> Sent: Thursday, July 22, 1999 3:57 PM
> To: Papezik Milon
> Cc: [EMAIL PROTECTED]
> 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
> <[EMAIL PROTECTED]>
>
> :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
> :--
> :[EMAIL PROTECTED]
> :
> :
> :------------ 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
