The history behind all this is that on the BG/P, important I/O codes fail on
1,000 processes because MPI_Aint is 32-bit, and those codes access large files with derived datatypes that use MPI_Aint. We have been after IBM to fix it somehow, otherwise the machine would be unusable for such codes.
The easiest fix we and IBM could come up with was to bump up the size of MPI_Aint. It turned out to be less trivial than I had thought because the code assumes sizeof(void *) = sizeof(MPI_Aint) in many places, which required going through the code carefully and type casting etc. We had also volunteered to provide IBM with a test suite to test the correctness of these changes. IBM has been bugging us for these tests, and Rob Latham has provided them with a few, but they would like more. So, while we need not use IBM's exact fixes, we should fix it in some way -- whatever way we think is right. We can then try to propagate those fixes back to IBM. We should also get it fixed in the MPI Standard -- in 3.0 or 2.2, wherever it belongs. What exactly is the issue with the attribute routines? Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Saturday, May 03, 2008 12:34 AM To: [email protected] Subject: Re: [mpich2-core] BG/P patches
Maybe you haven't been in on the conversation related to this? The issue is that MPI_Aint is the size for extents, even in I/I space, and so we need it to be 64 bit to be able to do useful file I/I (think subarray access from many processes).
Ah, got it. Thanks. I saw this discussion earlier, but couldn't pin-point the reason. So, we do want to accept the MPI_AINT_TO_VOID_PTR and family related parts of the patches, correct?
We'll probably also need to go through the entire code to make sure there are no random typecasts from MPI_Aint to (void *); the other way should be fine.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji