From owner-freebsd-current Mon Mar 20 13:21:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9ED0337BA83; Mon, 20 Mar 2000 13:17:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA71771; Mon, 20 Mar 2000 13:17:08 -0800 (PST) (envelope-from dillon) Date: Mon, 20 Mar 2000 13:17:08 -0800 (PST) From: Matthew Dillon Message-Id: <200003202117.NAA71771@apollo.backplane.com> To: Alfred Perlstein Cc: Poul-Henning Kamp , current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: I/O clustering, Re: patches for test / review References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> <20000320125317.E14789@fw.wintelcom.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :* Poul-Henning Kamp [000320 12:03] wrote: :> In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes: :> >* Poul-Henning Kamp [000320 11:45] wrote: :> >> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes: :> >> :> >> >Keeping the currect cluster code is a bad idea, if the drivers were :> >> >taught how to traverse the linked list in the buf struct rather :> >> >than just notice "a big buffer" we could avoid a lot of page :> >> >twiddling and also allow for massive IO clustering ( > 64k ) :> >> :> >> Before we redesign the clustering, I would like to know if we :> >> actually have any recent benchmarks which prove that clustering :> >> is overall beneficial ? :> > :> >Yes it is really benificial. :> :> I would like to see some numbers if you have them. : :No I don't have numbers. : :Committing a 64k block would require 8 times the overhead of bundling :up the RPC as well as transmission and reply, it may be possible :to pipeline these commits because you don't really need to wait Clustering is extremely beneficial. DG and I and I think even BDE and Tor have done a lot of random tests in that area. I did a huge amount of clustering related work while optimizing NFSv3 and fixing up the random/sequential I/O heuristics for 4.0 (for both NFS and UFS). The current clustering code does a pretty good job and I would hesitate to change it at this time. The only real overhead comes from the KVA pte mappings for b_data in the pbuf that the clustering (and other) code uses. I do not think that redoing the clustering will have a beneficial result until *after* we optimize the I/O path as per my previous posting. Once we optimize the I/O path to make it more VM Object centric, it will make it a whole lot easier to remove *ALL* the artificial I/O size limitations. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message