Messages in this thread | | | Date | Fri, 4 Nov 2022 12:35:57 +0800 | From | Chen Yu <> | Subject | Re: [RFC PATCH v2 2/2] sched/fair: Choose the CPU where short task is running during wake up |
| |
On 2022-11-03 at 14:04:43 +0100, Peter Zijlstra wrote: > On Sun, Oct 23, 2022 at 11:33:39PM +0800, Chen Yu wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 8820d0d14519..3a8ee6232c59 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -6249,6 +6249,11 @@ wake_affine_idle(int this_cpu, int prev_cpu, int sync) > > if (available_idle_cpu(prev_cpu)) > > return prev_cpu; > > > > + /* The only running task is a short duration one. */ > > + if (cpu_rq(this_cpu)->nr_running == 1 && > > + is_short_task(cpu_curr(this_cpu))) > > + return this_cpu; > > + > > return nr_cpumask_bits; > > } > > This is very close to using is_short_task() as dynamic WF_SYNC hint, no? > Yes. I think a short task waker is a subset of WF_SYNC wake up, because a short task waker might go to sleep soon after wakeup the wakee. > > @@ -6623,6 +6628,23 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool > > /* overloaded LLC is unlikely to have idle cpu/core */ > > if (nr == 1) > > return -1; > > + > > + /* > > + * If nr is smaller than 60% of llc_weight, it > > + * indicates that the util_avg% is higher than 50%. > > + * This is calculated by SIS_UTIL in > > + * update_idle_cpu_scan(). The 50% util_avg indicates > > + * a half-busy LLC domain. System busier than this > > + * level could lower its bar to choose a compromised > > + * "idle" CPU, so as to avoid the overhead of cross > > + * CPU wakeup. If the task on target CPU is a short > > + * duration one, and it is the only running task, pick > > + * target directly. > > + */ > > + if (!has_idle_core && (5 * nr < 3 * sd->span_weight) && > > + cpu_rq(target)->nr_running == 1 && > > + is_short_task(cpu_curr(target))) > > + return target; > > } > > } > > And here you're basically saying that if the domain is 'busy' and the > task is short, don't spend time searching for a better location. > > Should we perhaps only consider shortness; after all, spending more time > searching for an idle cpu than the task would've taken to run is daft. > Business of the domain seems unrelated to that. I see, the this_sd->avg_scan_cost could be used for the comparison, I'll have a try. > > > Also, I'm not sure on your criteria for short; but I don't have enough > thoughts on that yet. Yes, the criteria to define a short task is arbitrary. If we compare the avg_duration of a task with the sd->avg_scan_cost then we can skip the defination of short task.
thanks, Chenyu
| |