| |||||||||||||
How 3.6 nearly broke PostgreSQLHow 3.6 nearly broke PostgreSQLPosted Oct 3, 2012 12:03 UTC (Wed) by ajb (subscriber, #9694)In reply to: How 3.6 nearly broke PostgreSQL by Zenith Parent article: How 3.6 nearly broke PostgreSQL
Your example has convinced me that I was wrong to say that you could get away with only two buddies. If you have only two, the best you can do is have a ring of cpus. This is different from the case of cuckoo hashing and skew caches, where only two places are sufficient.
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.
(Log in to post comments)
How 3.6 nearly broke PostgreSQL Posted Oct 3, 2012 13:31 UTC (Wed) by and (subscriber, #2883) [Link]
I understood that approach differently: If core A has B as its buddy, B's buddy does not necessarily need to be A. This would imply kind of a ring buffer of buddies within the package (A->B->C->D->A)...
|
|||||||||||||