On 19/09/2019 17:41, Parth Shah wrote: > So jotting down separately, in case if we think to have "latency-nice" > terminology, then we might need to select one of the 2 interpretation: > > 1). >> -20 (least nice to latency, i.e. sacrifice latency for throughput) >> +19 (most nice to latency, i.e. sacrifice throughput for latency) >> > > 2). > -20 (least nice to other task in terms of sacrificing latency, i.e. > latency-sensitive) > +19 (most nice to other tasks in terms of sacrificing latency, i.e. > latency-forgoing) > >
I'd vote for 1 (duh) but won't fight for it, if it comes to it I'd be happy with a random draw :D >> Aren't we missing the point about tweaking the sched domain scans (which >> AFAIR was the original point for latency-nice)? >> >> Something like default value is current behaviour and >> - Being less latency-sensitive means increasing the scans (e.g. trending >> towards only going through the slow wakeup-path at the extreme setting) >> - Being more latency-sensitive means reducing the scans (e.g. trending >> towards a fraction of the domain scanned in the fast-path at the extreme >> setting). >> > > Correct. But I was pondering upon the values required for this case. > Is having just a range from [-20,19] even for larger system sufficient enough? > As I said in the original thread by Subhra, this range should be plenty enough IMO. You get ~5% deltas in each direction after all. >>> >> >> $> Load balance tuning >> ====================== >> >> Already mentioned these in [4]: >> >> - Increase (reduce) nr_balance_failed threshold when trying to active >> balance a latency-sensitive (non-latency-sensitive) task. >> >> - Increase (decrease) sched_migration_cost factor in task_hot() for >> latency-sensitive (non-latency-sensitive) tasks. >> > > Thanks for listing down your ideas. > > These are pretty useful optimization in general. But one may wonder if we > reduce the search scans for idle-core in wake-up path and by-chance selects > the busy core, then one would expect load balancer to move the task to idle > core. > > If I got it correct, the in such cases, the sched_migration_cost should be > carefully increased, right? > IIUC you're describing a scenario where we fail to find an idle core due to a wakee being latency-sensitive (thus shorter scan), and place it on a rq that already has runnable tasks (despite idle rqs being available). In this case yes, we could potentially have a balance attempt trying to pull from that rq. We'd try to pull the non-running tasks first, and if a latency-sensitive task happens to be one of them we should be careful with what we do - a migration could lead to unwanted latency. It might be a bit more clear when you're balancing between busy cores - overall I think you should try to migrate the non-latency-sensitive tasks first. Playing with task_hot() could be one of the ways to do that, but it's just a suggestion at this time. > >>>> References: >>>> =========== >>>> [1]. https://lkml.org/lkml/2019/8/30/829 >>>> [2]. https://lkml.org/lkml/2019/7/25/296 >>> >>> [3]. Message-ID: <20190905114709.gm2...@hirez.programming.kicks-ass.net> >>> >>> https://lore.kernel.org/lkml/20190905114709.gm2...@hirez.programming.kicks-ass.net/ >>> >> >> [4]: https://lkml.kernel.org/r/3d3306e4-3a78-5322-df69-7665cf01c...@arm.com >> >>> >>> Best, >>> Patrick >>> > > Thanks, > Parth >
