Add "extra info" field to the records #332
Conversation
probably paranoia, but just in case a compiler is set to turn warnings into errors, let's explicitly initialize these parameters to MPI_File_open (even though it's a compile-only check and will never execute)
We can obtain the implicit file pointer with MPI_File_get_position. Similar routine for the shared file pointer. Explicit file ponters already provide an offset. In all three cases MPI_File_get_byte_offset turns "offsets in terms of file types" into an explicit count of bytes, so I stuck _get_byte_offset into the MPIIO_RECORD_ macro.
|
In GitLab by @carns on Feb 28, 2018, 13:04 I would vote for a dynamic approach for sure. 64 bytes per access is too much for the general case. How do you use it exactly? Do you just do putenv() in the code you are annotating to pass information that will show up in DXT? In that case, maybe a doc update with the pull request too just so we can remember how to use it when needed :) |
|
In GitLab by @roblatham00 on Apr 20, 2020, 10:38 added 152 commits |
|
In GitLab by @roblatham00 on May 1, 2020, 15:16 closed |
|
In GitLab by @roblatham00 on May 1, 2020, 15:17 Uh looks like I force-pushed and overwrote these changes. I'll have to find the old work and dust it off; might not even still be a good idea. |
|
Not saying the idea is any good, but it wasn't a ton of work to update to main. |
|
revisit this work in #979 |
In GitLab by @roblatham00 on Feb 21, 2018, 14:45
I did this a while back on intel-hpdd's repo, where it seems to have been forgotten.
I have sometimes needed to annotate log fields with extra information. for example, in ROMIO, it was helpful to know which round of two-phase collective I/O an operation happened in.
I suspect EXTRA_INFO would be used rarely, so adding 64 bytes to a log entry all the time seems wasteful. Can switch to a more dynamic approach where EXTRA_INFO allocated only if environment variable set if that seems better