> On Jul 12, 2016, at 12:01 AM, Sreenidhi Bharathkar Ramesh > <sreenidhi-bharathkar.ram...@broadcom.com> wrote: > > [ query regarding an old thread ] > > Hi, > > It looks like "--disable-smp-locks" is still available as an option. > > 1. Will this be continued or deprecated ?
It was completely discontinued. The problem with the option is it made the opal_atomic_* functions non-atomic (on x86 at least). That is fine if there is only a single core in use on a node but caused problems with shared memory communication. The shared memory transports absolutely need the atomics to be atomic to work correctly. This RFC came up because users were trying to use the option and were running into issues. Made sense to just kill it. > 2. Under what circumstances would "--disable-smp-locks" be useful ? > In our experiments on ARM64 platform, it was seen that OSU Micro collective > benchmarks actually degraded when "--disable-smp-locks" was used. Hence, > asking. The optimization was likely meant for MPI_THREAD_SINGLE. The problem is we already optimize that case with the OPAL_THREAD_* macros which use atomics only if threads are in use. Others may be able to explain the intent. -Nathan
