Hi, just thought I'd throw my two cents in here....

On Thu, 2007-08-09 at 09:33 -0500, Robert Latham wrote:
> On Wed, Aug 08, 2007 at 06:47:41PM -0500, Sam Lang wrote:
> > Also, should we increase the limit of request segments allowed?  It  
> > might be inefficient for a user to create an MPI indexed dataype with  
> > that many elements, but there are users that will probably do it  
> > anyway.  Alternatively, we could consider more efficiently encoding  
> > each request segment in PVFS.
> 
> Bear in mind that Joe User is probably going to create these PVFS
> types through ROMIO.  Since we take a list-io approach and turn all
> types into offset-length pairs (the indexed type), what could be a
> very compact MPI type might become a quite long PVFS type (for
> example, some of the types created by the HDF5 test programs contain
> 512 offset-length pairs once they make their way down to
> ADIOI_PVFS2_WriteStrided)
> 
> I'd like to see a few things:
> 
> - a way to ask PVFS how many segments romio can produce.  that's
>   hard-coded to 64 now, but clearly should have been less in this case
>   and more for TCP.
> 

Seems like a higher limit would be a big performance benefit for apps
that have a large number of pieces in our past experiments.

> - a way to announce to PVFS "hey, i'm about to send you a giant
>   request".  I'm 100% ok with a rendezvous approach if those
>   additional messages mean a single call to PVFS_sys_io

This would simply the ROMIO implementation at the risk of potentially
requiring huge resources from the clients and servers.  

> - Real datatype I/O in ROMIO.  Avery's code has been languishing in a
>   branch for way too long, pending creation of a thourough ROMIO test
>   suite.  We have tested the PVFS_request_hindexed approach very well,
>   but other PVFS request types have not been used nearly as often.  
> 

I have a pretty exhaustive MPI-IO test suite test as part of HPIO.  I'd
be happy to help the PVFS team get this used and add more funky access
patterns to it.  The best thing to do might be to have the default set
to "list I/O" and then have users try out "datatype I/O" via a hint if
they want to see how it performs.  My code also supports darray and
subarray via the ROMIO helper functions....

> ==rob
> 

_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to