On Thu, 27 Sep 2012, Peter Zijlstra wrote:
On Thu, 2012-09-27 at 09:48 -0700, da...@lang.hm wrote:
I think you are bing too smart for your own good. you don't know if it's
best to move them further apart or not.
Well yes and no.. You're right, however in general the load-balancer has
always tried to not use (SMT) siblings whenever possible, in that regard
not using an idle sibling is consistent here.
Also, for short running tasks the wakeup balancing is typically all we
have, the 'big' periodic load-balancer will 'never' see them, making the
multiple moves argument hard.
For the initial starup of a new process, finding as idle and remote a core
to start on (minimum sharing with existing processes) is probably the
smart thing to do.
But I thought that this conversation (pgbench) was dealing with long
running processes, and how to deal with the overload where one master
process is kicking off many child processes and the core that the master
process starts off on gets overloaded as a result, with the question being
how to spread the load out from this one core as it gets overloaded.
David Lang
Measuring resource contention on the various levels is a fun research
subject, I've spoken to various people who are/were doing so, I've
always encouraged them to send their code just so we can see/learn, even
if not integrate, sadly I can't remember ever having seen any of it :/
And yeah, all the load-balancing stuff is very near to scrying or
tealeaf reading. We can't know all current state (too expensive) nor can
we know the future.
That said, I'm all for less/simpler code, pesky benchmarks aside ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/