Hi George, > On Sep 21, 2023, at 20:23, George Dunlap <[email protected]> wrote: > > The credit scheduler tries as hard as it can to ensure that it always > runs scheduling units with positive credit (PRI_TS_UNDER) before > running those with negative credit (PRI_TS_OVER). If the next > runnable scheduling unit is of priority OVER, it will always run the > load balancer, which will scour the system looking for another > scheduling unit of the UNDER priority. > > Unfortunately, as the number of cores on a system has grown, the cost > of the work-stealing algorithm has dramatically increased; a recent > trace on a system with 128 cores showed this taking over 50 > microseconds. > > Add a parameter, load_balance_ratelimit, to limit the frequency of > load balance operations on a given pcpu. Default this to 1 > millisecond. > > Invert the load balancing conditional to make it more clear, and line > up more closely with the comment above it. > > Overall it might be cleaner to have the last_load_balance checking > happen inside csched_load_balance(), but that would require either > passing both now and spc into the function, or looking them up again; > both of which seemed to be worse than simply checking and setting the > values before calling it. > > On a system with a vcpu:pcpu ratio of 2:1, running Windows guests > (which will end up calling YIELD during spinlock contention), this > patch increased performance significantly. > > Signed-off-by: George Dunlap <[email protected]>
Release-acked-by: Henry Wang <[email protected]> Kind regards, Henry
