<tt><font size=2><br>
> From: Rob Ross <rross@mcs.anl.gov></font></tt>
<br><tt><font size=2>> <br>
> Should we consider this as interest in working on this problem on
<br>
> the IBM side :)? -- Rob<br>
</font></tt>
<br><tt><font size=2>Say what?! ;)</font></tt>
<br>
<br><tt><font size=2>Meaning we can get rid of all o(p) allocations?  Not
sure how you do internal collectives on behalf of the app/mpi-io without
at least some of those.  I was looking more for agreement that collective
i/o is 'what it is'... and maybe some idea if we just have some known limitations
on scaling it.  Yes, that BG alltoallv is a bigger problem that we
can avoid with an env var -- is that just going to have to be 'good enough'?
 (I think that Jeff P wrote that on BG/P and got good performance
with that alltoallv.  Trading memory for performance, not unusual,
and at least it's selectable.)</font></tt>
<br>