User: Password:
|
|
Subscribe / Log in / New account

How 3.6 nearly broke PostgreSQL

How 3.6 nearly broke PostgreSQL

Posted 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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds