<br><font size=2 face="sans-serif">I was looking at the "hole"
detection and read-modify-write processing in ad_write_coll (and ad_bgl_wrcoll).</font>
<br>
<br><font size=2 face="sans-serif">I notice that it very intentionally
looks for front and back holes. Any hole causes read-modify-write.
But what if the only hole found is front or back? Was
there any effort to just skip front/back holes? Avoid the read and
adjust the write to only write where there's data? Adjust the offset
and length to skip the front/back holes? Or is it not worth it on
typical collective i/o patterns?</font>
<br>
<br><font size=2 face="sans-serif">I have a customer complaint that a particular
testcase performs poorly with MPI_File_write_at_all. For the most
part, it's just a testcase that shouldn't be using collective i/o. Each
rank writes large contiguous blocks to it's own range of the file. So
aggregation is just a waste of time. Each write the aggregator does
is a large contiguous write for a single rank. So there's really
no true aggregation.</font>
<br>
<br><font size=2 face="sans-serif">What caught my eye was, for example,
using a 16MB cb_buffer_size and writing a contiguous 1M block causes
read-modify-write of the whole 16M because of the single large (15M) trailing
(or leading) hole. It just seems like we should do better, but is
it worth doing anything for something that probably isn't a true collective
i/o pattern?</font>
<br>
<br><font size=2 face="sans-serif">I can fix the testcase performance by
hinting cb_buffer_size down to 1MB and then there's no hole. This
is a fine user circumvention, but I'm trying to decide if we should do
more.</font>
<br>
<br><font size=2 face="sans-serif">Thoughts?</font>
<br><font size=2 face="sans-serif"><br>
Bob Cernohous: (T/L 553) 507-253-6093<br>
<br>
BobC@us.ibm.com<br>
IBM Rochester, Building 030-2(C335), Department 61L<br>
3605 Hwy 52 North, Rochester, MN 55901-7829<br>
<br>
> Chaos reigns within.<br>
> Reflect, repent, and reboot.<br>
> Order shall return.<br>
</font>