enable-fast

[balaji]

Bcast seems to be hanging with enable-fast in the new nightly tests: http://www.mcs.anl.gov/research/projects/mpich2/nightly/new/latest

[thakur]

I can reproduce this by hand. Built with --enable-fast on thrash. bcast2 runs up to 8 processes. On 10 procs, which triggers the long msg algorithm, it hangs.

[thakur]

No, it works. It just takes a while.

thrash:/sandbox/thakur/tmp/test/mpi/coll% date; mpiexec -n 10 bcast2; date
Fri Nov  6 16:20:28 CST 2009
 No Errors
Fri Nov  6 16:24:10 CST 2009

[thakur]

I ran all the tests in the coll directory. They all completed.

[goodell]

So this is just the usual nemesis over-subscription issue being aggravated by tighter loops from --enable-fast, right? Is there anything that actually needs to be done here in the short term?

[thakur]

Probably not. Resolving it for now.

[balaji]

Is the problem with the sched_yield() call alone, or other CPU yielding calls as well (e.g., usleep(0) or select())? If this is specific to sched_yield, shouldn't we just give a higher priority to pick one of the other routines before trying sched_yield?

[thakur]

With the default build, the coll tests go through real fast. That --enable-fast makes the oversubscription case real slow is something to look into, but maybe not for this release. Reopening.

[buntinas]

Yes, we should look into select() or sleep() as alternatives.

Hmm. I wonder if --enable-fast disables yield...