No, we really shouldn't. Having just fought with a program using usleep(1) which was behaving even worse, working around this particular inability of the Linux kernel development team to do something sane will only lead to more pain. There are no good options, so the best option is to not try to work around a (hopefully temporary) stupidity in the Linux kernel.
Brian On Jul 23, 2010, at 5:27 AM, Jeff Squyres wrote: > 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. >> >> David >> >> 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.ro...@mcgill.ca> >>>> 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 >> us...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/users >> > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories
