Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Wed, 14 Jun 2006 13:09 -0500:
I've attached a patch of the sys-io state machine from trunk that
doesn't post the flow until the initial response is received. Phil
and Murali, can you let me know if this fixes your respective
problems? Also, if you get a chance Pete, can you see what kind of
performance degradation this causes for you?
I tested with and without the patch, at a variety of sizes with a
single client, and could not see any performance difference.
Since it fixes Phil's issue, suggest you check it in.
We did some limited performance testing and also didn't see any
performance difference.
I did find one odd result, although it is somewhat unrelated. In an
earlier email on this topic I mentioned that I was able to find a
temporary workaround for the bug by setting PVFS2_BUFMAP_DESC_COUNT to
1, which limits pvfs2-client-core to only performing one I/O operation
at a time. A surprising side effect of this was that (regardless of the
flow post order) this configuration substantially increased performance
for a 5 process I/O benchmark.
In this particular test there are 5 processes, each both reading and
writing large files on the same PVFS2 file system. The results are
counter-intuitive, because the whole point of having multiple buffers
was to allow more concurrent activity when multiple processes perform
I/O. However, the test went faster when only one I/O operation was
allowed to proceed at a time.
I don't have time to dig into this much further right now, but I just
wanted to share on the mailing list in case anyone else was interested.
-Phil
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
