From owner-freebsd-stable Mon Dec 14 18:49:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA27568 for freebsd-stable-outgoing; Mon, 14 Dec 1998 18:49:08 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from dingo.cdrom.com (goldfish.pht.co.jp [210.171.55.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA27563 for ; Mon, 14 Dec 1998 18:49:07 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA02006; Mon, 14 Dec 1998 18:47:05 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812150247.SAA02006@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Michael Robinson cc: freebsd-stable@FreeBSD.ORG Subject: Re: MLEN < write length < MINCLSIZE "bug" In-reply-to: Your message of "Mon, 14 Dec 1998 14:37:09 GMT." <199812141437.OAA00472@netrinsics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Dec 1998 18:47:04 -0800 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I previously wrote: > >Which brings us back to where we started. Squid and ORBit (at the very > >least) exhibit severe performance degradation with the current > >MLEN < write length < MINCLSIZE bug. There isn't an open PR (that I can > >find), and the Squid FAQ advocates a kernel patch that breaks X Windows > >(among other things). > > > >If someone who is familiar with the fundamental problem could explain it > >to me in more detail, along with some possible solutions, I could try to > >play with it. > > Well, no one explained it to me, but I played with it anyway. I've come to > the following conclusions: > > 1. This isn't a bug. It's a performance tradeoff of memory efficiency > (allocating an mbuf cluster) versus protocol efficiency (sending > two packets). > > 2. MINCLSIZE is an arbitrary value. It only serves to set the threshold > for the above performance tradeoff. > > 3. For certain applications which are latency-sensitive and send many > packets in the MLEN < len < MINCLSIZE range over TCP (such as SQUID > and IIOP), the current threshold setting is completely inappropriate. > However, for other applications (such as large FTP servers), reducing > MINCLSIZE would be completely inappropriate. > > 4. One solution is to make MINCLSIZE a kernel config option. This is ugly, > but simple to implement and relatively non-intrusive. It should be a sysctl variable, not a kernel option, in this case. But that's certainly the simplest way to go. Want to implement this? > 5. Another solution is to add a socket option, and modify kern/uipc_socket.c > something like this: > > - if (resid >= MINCLSIZE) { > + if ((resid >= MINCLSIZE) || > + ((resid > MLEN) && (so->so_options & SO_NOSPLIT))) { > MCLGET(m, M_WAIT); > if ((m->m_flags & M_EXT) == 0) > goto nopages; > mlen = MCLBYTES; > len = min(min(mlen, resid), space); > } else { > > With a socket option, applications that wanted low latency (at the > expense of more memory usage) could specify that on a per-socket basis. > This is less ugly, but requires extensive changes to documentation, > header files, and application software. Do you think you could come up with a heuristic that would be able to detect when the current behaviour was losing, reliably? If so, you could use this to switch the option... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message