Messages in this thread | | | Date | Fri, 26 Apr 2019 20:49:22 +0100 | From | Mel Gorman <> | Subject | Re: [RFC PATCH v2 00/17] Core scheduling v2 |
| |
On Fri, Apr 26, 2019 at 11:37:11AM -0700, Subhra Mazumdar wrote: > > > So we avoid a maybe 0.1% scheduler placement overhead but inflict 5-10% > > > harm on the workload, and also blow up stddev by randomly co-scheduling > > > two tasks on the same physical core? Not a good trade-off. > > > > > > I really think we should implement a relatively strict physical core > > > placement policy in the under-utilized case, and resist any attempts to > > > weaken this for special workloads that ping-pong quickly and benefit from > > > sharing the same physical core. > > > > > It's worth a shot at least. Changes should mostly be in the wake_affine > > path for most loads of interest. > > Doesn't select_idle_sibling already try to do that by calling > select_idle_core? For our OLTP workload we infact found the cost of > select_idle_core was actually hurting more than it helped to find a fully > idle core, so a net negative. >
select_idle_sibling is not guarnateed to call select_idle_core or avoid selecting HT sibling whose other sibling is !idle but yes, in that path, the search cost is a general concern which is why any change there is tricky at best.
-- Mel Gorman SUSE Labs
| |