Date: Mon, 20 Mar 2000 13:17:08 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: I/O clustering, Re: patches for test / review Message-ID: <200003202117.NAA71771@apollo.backplane.com> References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> <20000320125317.E14789@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 12:03] wrote:
:> In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes:
:> >* Poul-Henning Kamp <phk@critter.freebsd.dk> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003202117.NAA71771>