Should we replace OMPI's use of sched_yield() with usleep()?
David -- could you try replacing the call to sched_yield() in opal/runtime/opal_progress.c (somewhere around line 220) to usleep(1) and see if that gives the behavior that you want (without twonking a /proc value)? You might also have to add "#include <unistd.h>" at the top of the file.
On Jul 22, 2010, at 12:03 PM, David Ronis wrote:
> That did it. Thanks.
> On Wed, 2010-07-21 at 15:29 -0500, Dave Goodell wrote:
> > On Jul 21, 2010, at 2:54 PM CDT, Jed Brown wrote:
> > > On Wed, 21 Jul 2010 15:20:24 -0400, David Ronis <David.Ronis_at_[hidden]> wrote:
> > >> Hi Jed,
> > >>
> > >> Thanks for the reply and suggestion. I tried adding -mca
> > >> yield_when_idle 1 (and later mpi_yield_when_idle 1 which is what
> > >> ompi_info reports the variable as) but it seems to have had 0 effect.
> > >> My master goes into fftw planning routines for a minute or so (I see the
> > >> threads being created), but the overall usage of the slaves remains
> > >> close to 100% during this time. Just to be sure, I put the slaves into
> > >> a MPI_Barrier(MPI_COMM_WORLD) while they were waiting for the fftw
> > >> planner to finish. It also didn't help.
> > >
> > > They still spin (instead of using e.g. select()), but call sched_yield()
> > > so should only be actively spinning when nothing else is trying to run.
> > > Are you sure that the planner is always running in parallel? What OS
> > > and OMPI version are you using?
> > sched_yield doesn't work as expected in late 2.6 Linux kernels: http://kerneltrap.org/Linux/CFS_and_sched_yield
> > If this scheduling behavior change is affecting you, you might be able to fix it with:
> > echo "1" >/proc/sys/kernel/sched_compat_yield
> > -Dave
> users mailing list
For corporate legal information go to: