| |||||||||||||
How 3.6 nearly broke PostgreSQLHow 3.6 nearly broke PostgreSQLPosted Oct 3, 2012 2:13 UTC (Wed) by ncm (subscriber, #165)Parent article: How 3.6 nearly broke PostgreSQL
It seems to me that a more lightly-loaded core should be put to work first recruiting work from its more heavily-loaded neighbors, offloading both scheduling activity and finally other processes from them. Is there something very cheap that a busy core could do that allows its neighbors to make better decisions about what work to take away from it?
(Log in to post comments)
How 3.6 nearly broke PostgreSQL Posted Oct 3, 2012 12:36 UTC (Wed) by rvfh (subscriber, #31018) [Link]
Unless I misread the code, it's more or less what happens now: if a core becomes idle and no load balancer exists in the system, it will start assuming that role and try to get some work to do.
How 3.6 nearly broke PostgreSQL Posted Oct 5, 2012 10:28 UTC (Fri) by amit.kucheria (subscriber, #59246) [Link]
Except when you're trying to optimize for power, which we're trying to do in the ARM world. :)
Consolidating work onto fewer cores[1] is something we're actively looking into.
[1] https://blueprints.launchpad.net/linaro-power-kernel/+spe...
How 3.6 nearly broke PostgreSQL Posted Oct 13, 2012 7:35 UTC (Sat) by rodgerd (guest, #58896) [Link]
Not just the ARM world, really; consider the turbo mode available with newer Intel and AMD processors. If you're doing work that runs better with fewer, faster threads rather than more slower ones, you'd want to aggregate the workload onto fewer cores and let the CPU ratchet the clock up.
|
|||||||||||||