Date: Tue, 15 Dec 1998 08:42:29 PST From: Bill Fenner <fenner@parc.xerox.com> To: Michael Robinson <robinson@netrinsics.com> Cc: fenner@parc.xerox.com, freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: MLEN < write length < MINCLSIZE "bug" Message-ID: <98Dec15.085714pst.177535@crevenia.parc.xerox.com> In-Reply-To: Your message of "Tue, 15 Dec 98 07:55:17 PST." <199812151555.PAA07456@netrinsics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199812151555.PAA07456@netrinsics.com> you write: >Together, these performance optimizations at different >levels of abstraction can interact badly, under a particular set of >circumstances, but is that really a bug, per se? Ok, it's a performance problem, which was introduced by a performance enhancement. Therefore, it's a bug in the original enhancement. =) >It seems that we only get the "parallelism" if the write length is more >than one mbuf and less than two. You get it also if it's more than the length of a cluster (and particularly multiples of the length of a cluster, e.g. a 64k write). >Is there any documentation on why MINCLSIZE is currently set to the value it >is? Not that I know of, but I can't say for sure that there's not something in the 4.4 daemon book. You know what the main tradeoff is of reducing MINCLSIZE (and there are some subtle ones too - set your socket buffer to 64k and start writing in 120-byte chunks and see when the socket buffer fills up). Bill 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?98Dec15.085714pst.177535>