How 3.6 nearly broke PostgreSQL
Posted Oct 3, 2012 8:07 UTC (Wed) by Zenith (subscriber, #24899)
Would a better solution than the one suggested by Mike not be to have 3 cores in each set, and then make the sets overlap.
So say we have a 4-core CPU (labelled A, B, C, and D), that then gets divided into two sets X = (A, B, C) and Y = (A, C, D).
That way the load can migrate from one set (X) of CPU's into another set (Y), provided that the load migration code gets lucky on selecting set Y.
Posted Oct 3, 2012 12:03 UTC (Wed) by ajb (subscriber, #9694)
However, in your example, A and C have 3 buddies, but B and D have only two. It seems like the scheduling algorithm would be just as efficient if they all had three, and there would be a better chance that migrations would be beneficial.
Posted Oct 3, 2012 13:31 UTC (Wed) by and (subscriber, #2883)
Posted Oct 4, 2012 10:46 UTC (Thu) by dunlapg (subscriber, #57764)
Posted Oct 6, 2012 8:13 UTC (Sat) by eternaleye (subscriber, #67051)
I've found this to be a far clearer explanation than the Wikipedia article: http://pl.atyp.us/wordpress/index.php/2007/12/the-kautz-g...
In learning about them myself, I wrote a perl script to generate a Kautz graph: http://ix.io/36j/
It takes the degree as the first argument and the dimension and the second, and outputs a list of edges as <from> <to> tuples, one per line.
I still need to write the Kautz::Graph class (stubbed in the file above) to embody a full set of the Kautz nodes with the same degree and dimension parameters, and see about modifying it to generate dot so it can make a nice graphic.
Posted Oct 6, 2012 8:26 UTC (Sat) by eternaleye (subscriber, #67051)
Well, one more thing to remedy.
Posted Oct 6, 2012 8:45 UTC (Sat) by eternaleye (subscriber, #67051)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds