On Tue, Apr 05, 2016 at 02:43:09PM -0400, Bastien Bastien Philbert wrote: > On Tue, Apr 5, 2016 at 2:08 PM, Chris Mason <[email protected]> wrote:
[ ... ] > > > > I tried a few variations on select_idle_sibling() that preserved the > > underlying goal of returning idle cores before idle SMT threads. They > > were all horrible in different ways, and none of them were fast. > > > > The patch below just makes select_idle_sibling pick the first idle > > thread it can find. When I ran it through production workloads here, it > > was faster than the patch we've been carrying around for the last few > > years. [ ... ] > > > Here is my concern, do you test this on standard scheduler workloads > or was this just written for Facebook's internal workloads. I am going > to test this later because frankly this may cause a regression on my > system which has only 4 cores so a idle CPU is probably less common > for a small amount of time. I am wondering however if Ingo has any > complains before I test this to see if it causes a regression or a bug > on my system. Ingo do you have any thoughts on this or would you like > me to just test this? Bastien Pretty much every commit to select_idle_sibling over the last few years was somehow trying to preserve or improve the select-idle-cores-first functionality I just ripped out. So, it's safe to assume it'll break something ;) -chris
