Feature sync #175
Feature sync #175
Conversation
| if (barriers) { | ||
| MPI_Barrier(testComm); | ||
| } | ||
| phase_end(); | ||
| t[1] = GetTimeStamp(); | ||
|
|
There was a problem hiding this comment.
Should phase_end() return GetTimeStamp()? Then you could combine these two lines with:
t[1] = phase_end();
There was a problem hiding this comment.
We could do that... Personally I find it more verbose to have GetTimeStamp() explicitly here.
| @@ -809,3 +809,10 @@ char *HumanReadable(IOR_offset_t value, int base) | |||
| } | |||
| return valueStr; | |||
| } | |||
|
|
|||
| void call_sync_cmd(){ | |||
| int ret = system("sync"); | |||
There was a problem hiding this comment.
I think the backends should have a sync routine. Isn't it better to call that than to do a system wide sync?
There was a problem hiding this comment.
Generally, a good suggestion. Not quite sure if and how any other backend would implement this.
I'd be happy if we proceed for now with MDTest and see if anyone else has another thought on the usefulness.
There was a problem hiding this comment.
I would vote for a sync routine (or routines? I haven't looked at the code) for backends. The default provided by the benchmark can print a warning along the lines of "Warning: mdtest configuration requested a sync, but backend XYZ does not implement that operation." so that benchmark users get some indication that they asked for something that the storage system doesn't know how to do. Backends that do support it can populate their own function pointer for that. Backends that already implicitly sync everything without being asked can provide a noop function pointer to hush the warning.
Calling the sync command line utility might produce some odd (or at least inconsistent) results since you don't know what file systems or directories might be affected. You could get a slow benchmark result just because the OS happened to have some changes to flush to a slow local SATA drive.
No description provided.