Provide a better fix for #6285. #6326
Conversation
ggouaillardet
changed the title
|
minor typo in the commit message, it should refer #6285 |
bosilca
force-pushed
the
fix/convertor_raw
branch
from
ec379ba to
e1d31c7
Compare
Looks like something is not right either with the test or the PR. |
|
@bosilca something is not quite right, the result is still not correct (although the offsets are different now). Will look into it later today to see whether I can provide more details. |
|
ok let me check again, on my machine all datatype tests pass. |
|
@bosilca I pushed an other commit to this PR. |
|
Oh the newbie mistake! I did had the feeling that my pull-rebase didn't quite worked but all my tests passed so I went ahead and pushed, and indeed I inherited both my fix and @ggouaillardet. Thanks @ggouaillardet for the better fix of the better fix. |
The issue was a little complicated due to the internal stack used in the convertor. The main issue was that in the case where we run out of iov space to save the raw description of the data while hanbdling a repetition (loop), instead of saving the current position and bailing out directly we reading of the next predefined type element. It worked in most cases, except the one identified by the HDF5 test. However, the biggest issue here was the drop in performance for all ensuing calls to the convertor pack/unpack, as instead of handling contiguous loops as a whole (and minimizing the number of memory copies) we copied data description by data description. Signed-off-by: George Bosilca <[email protected]>
bosilca
force-pushed
the
fix/convertor_raw
branch
from
5389d2a to
5a82c4f
Compare
|
I can confirm that the hdf5 data corruption reported by @ax3l and @psychocoderHPC is fixed with this commit. |
|
When this is merged I will also test again Don't forget to backport all related issues also to 2.X, please. |
5 participants
The issue was a little complicated due to the internal stack used in the
convertor. The main issue was that in the case where we run out of iov
space to save the raw description of the data while hanbdling a
repetition (loop), instead of saving the current position and bailing out
directly we reading of the next predefined type element. It worked in
most cases, except the one identified by the HDF5 test. However, the
biggest issue here was the drop in performance for all ensuing calls to
the convertor pack/unpack, as instead of handling contiguous loops as a
whole (and minimizing the number of memory copies) we copied data
description by data description.
Signed-off-by: George Bosilca [email protected]