:
:* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 12:03] wrote:
:> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
:> >* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote:
:> >> In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
