Hi,
> On 28 Mar 2017, at 2:00 am, r...@open-mpi.org wrote:
> I’m confused - mpi_yield_when_idle=1 is precisely the “oversubscribed”
> setting. So why would you expect different results?
Ahh — I didn’t realise it auto-detected this. I recall working on a system in
the past where I needed to explicitly set this to get that behaviour, but that
could have been due to some local site configuration.
> On 28 Mar 2017, at 2:51 am, Jeff Squyres (jsquyres) <jsquy...@cisco.com>
> wrote:
> 1. Recall that sched_yield() has effectively become a no-op in newer Linux
> kernels. Hence, Open MPI's "yield when idle" may not do much to actually
> de-schedule a currently-running process.
In some kernel versions there’s a sysctl (/proc/sys/kernel/sched_compat_yield)
that makes it mimic the older behaviour by putting the yielding task at the end
of the tree instead of the start. It was introduced in 1799e35 (2.6.23-rc7) and
removed in ac53db5 (2.6.39-rc1), so if you have a kernel in this range (e.g.
the stock CentOS or RHEL 6 kernel), it might be available to you.
As an aside, has anyone thought about changing the niceness of the thread
before yielding (and then back when sched_yield returns)? I just tested that
sequence and it seems to produce the desired behaviour.
On their own, and pinned to a single CPU, my test programs sat at 100% CPU
utilisations with these timings:
spin: 2.1ns per iteration
yield: 450ns per iteration
nice+yield: 2330ns per iteration
When I ran spin and yield at the same on the same CPU, both consumed 50% of the
CPU, and produced times about double of above — as expected given the new
sched_yield behaviour.
On the other hand, when I ran spin and nice+yield together, spin sat at 98.5%
CPU utilisation, nice+yield at 1.5%, and the timing for spin was identical to
when it was on its own.
The only problem I can see is that the timing for nice+yield increased
dramatically — to 187,600 ns per iteration! Is this too long for a yield?
Cheers,
Ben
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
