[PVFS2-developers] latest mpi-io-test numbers on jazz

Robert Latham robl at mcs.anl.gov
Thu Mar 31 15:57:41 EST 2005


On Thu, Mar 31, 2005 at 07:45:40PM +0200, Phil Carns wrote:
> There definitely needs to be some improvement here.  I think the most 
> important write graph is the "nosync" version, though.  According to the 
> rough calculations in the earlier email, that graph shows us getting 23 
> MB/s per server, which is close to 75% of peak.  Still not as good as we 
> could be, though.

How smart is the request scheduler these days?  

> I don't think that the runs with TroveSync set to yes really tell us 
> that much.  Those are forcing trove to sync after every individual 
> underlying operation (which can be no larger than 256K each by default) 
> whether the application wants it to or not.  That's adding a good bit of 
> superfluous work to a benchmark that is already syncing the traditional 
> way by just calling a sync() function once at the end of a write.  It is 
> also probably causing blocks to flush to disk in an unusual order given 
> the interleaving of data from many clients, therefore causing extra disk 
> latency.

Wow, I didn't realize we were syncing after every 256K bytes!  

> PVFS2 ships with the default configuration files setting TroveSync to 
> yes, though, so I guess that's really showing PVFS2's normal mode of 
> operation.  IMHO, I tend to think that turning TroveSync off is a better 
> default choice.  Maybe at least until we have a server controlled cache 
> that prevents us from hitting trove unless we really want to hit 
> physical disk.  Applications still have the choice of deciding when/if 
> to explicitly sync regardless of the TroveSync option.

I'm trying to learn how frequently berkely db will flush data if
clients never call db->sync.  Even though we've worked out a lot of
sofware reasons for server crashes, we still see hardware blowups.
Just curious how exposed people are to data loss if sync is off.

==rob

-- 
Rob Latham
Mathematics and Computer Science Division    A215 0178 EA2D B059 8CDF
Argonne National Labs, IL USA                B29D F333 664A 4280 315B


More information about the PVFS2-developers mailing list