Manytomany on PAMI SMP hangs without Async
charm++/penciltest and NAMD with optPME/manytomany set to 1 hangs for SMP (without async). ASYNC works
- Description updated (diff)
- Target version changed from Unscheduled to 6.5.1
Sameer confirmed the issue and said he will fix it:
I looked at the manytomany implementation and its broken for SMP w/o ASYNC. I will fix this asap. Please use manytomany with ASYNC enable till I can fix that.
- Status changed from New to Upstream
Sameer's not registered here, so we can't just assign it to him. He is upstream for this in a sense, though, so set that to indicate that it's not on our plate.
Any word from Sameer about progress on this?
I have not heard anything back from Sameer
- Target version changed from 6.5.1 to 6.5.2
- Target version changed from 6.5.2 to 6.7.0
Short-term change noted in #302. Keeping this open and future-targeted for long-term fix.
- Subject changed from Manytomany on PAMI to Manytomany on PAMI SMP hangs without Async
- Status changed from Upstream to In Progress
Temporary solution is to force user compile charm with async if they use many to many. Other abort.
For all many-to-many interface, I added the following
#if CMK_SMP && !CMK_ENABLE_ASYNC_PROGRESS
CmiAbort("!!!!!!!!!Please build Charm++ with async in order to use many-to-many interface\n");
- Status changed from In Progress to Upstream
I split the checking off to #302 so that we can clearly track our interactions with IBM over this issue here.
- Assignee changed from Yanhua Sun to PPL
- Target version changed from 6.7.0 to 6.8.0
- Target version changed from 6.8.0 to 6.8.1
- Target version changed from 6.8.1 to 6.9.0
- Target version deleted (
- Assignee changed from PPL to Eric Bohm
- Target version set to 6.9.1
Old CkDirect based version slated for removal. PAMI support for this appears to be dead. Basic idea needs reconstruction in context of zerocopy.
- Status changed from Upstream to Rejected
- Target version changed from 6.9.1 to Unscheduled
Also available in: Atom