Date: Mon, 14 Dec 1998 18:47:04 -0800 From: Mike Smith <mike@smith.net.au> To: Michael Robinson <robinson@netrinsics.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: MLEN < write length < MINCLSIZE "bug" Message-ID: <199812150247.SAA02006@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 14 Dec 1998 14:37:09 GMT." <199812141437.OAA00472@netrinsics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812150247.SAA02006>