This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Nicolas Bock wrote:
In my (limited) experience, the situation is a little of both. OMPI is
yielding. Yielding makes a difference only if someone else wants the
CPU. But even if someone else wants the CPU, OMPI in yield mode will
still be consuming cycles. It's like the way I drive a car. When I
approach a stop sign, I slow down -- really, officer, I do -- and if
there is cross traffic I let it go by ahead of me. But if there is no
cross traffic, I, ahem, proceed expediently. And, even if there is
cross traffic, their progress is still impacted by me -- heck, I'm all
for obeying stop signs and all, but I'm no doormat. OMPI processes can
yield, but they only check to yield every now and then. Between
checks, they are not timid processes, even if other processes are
waiting to run. I once had some numbers on this. Yield helped, but
not as effectively as one might have imagined.
When you say "the other proc would take some", how much do you expect
it to take? In my case above, the master process does not appear to
yield a whole lot. Can I reduce the polling frequency? I know that my
slave processes typically run several minutes to hours.
On Fri, Dec 4, 2009 at 08:21, Ralph Castain <firstname.lastname@example.org>
You used it correctly. Remember, all that cpu number
is telling you is the percentage of use by that process. So bottom line
is: we are releasing it as much as we possibly can, but no other
process wants to use the cpu, so we go ahead and use it.
If any other process wanted it, then the percentage would drop
and the other proc would take some.