> > > > I also think a way to make fairness per cookie per core, is this what you > > want to propose? > > Yes, that's what I meant.
I think that would hurt some kind of workloads badly, especially if one tenant is having way more tasks than the other. Tenant with more task on the same core might have immediate requirements from some threads than the other and we would fail to take that into account. With some hierarchical management, we can alleviate this, but as Aaron said, it would be a bit messy. Peter's rebalance logic actually takes care of most of the runq imbalance caused due to cookie tagging. What we have found from our testing is, fairness issue is caused mostly due to a Hyperthread going idle and not waking up. Aaron's 3rd patch works around that. As Julien mentioned, we are working on a per thread coresched idle thread concept. The problem that we found was, idle thread causes accounting issues and wakeup issues as it was not designed to be used in this context. So if we can have a low priority thread which looks like any other task to the scheduler, things becomes easy for the scheduler and we achieve security as well. Please share your thoughts on this idea. The results are encouraging, but we do not yet have the coresched idle to not spin 100%. We will soon post the patch once it is a bit more stable for running the tests that we all have done so far. Thanks, Vineeth
