lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Sep 2022 18:49:39 +0800 From: Chen Yu <yu.c.chen@...el.com> To: Tim Chen <tim.c.chen@...ux.intel.com> CC: Peter Zijlstra <peterz@...radead.org>, Vincent Guittot <vincent.guittot@...aro.org>, Tim Chen <tim.c.chen@...el.com>, Mel Gorman <mgorman@...hsingularity.net>, Juri Lelli <juri.lelli@...hat.com>, "Rik van Riel" <riel@...riel.com>, Aaron Lu <aaron.lu@...el.com>, Abel Wu <wuyun.abel@...edance.com>, K Prateek Nayak <kprateek.nayak@....com>, "Yicong Yang" <yangyicong@...ilicon.com>, "Gautham R . Shenoy" <gautham.shenoy@....com>, Ingo Molnar <mingo@...hat.com>, Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Daniel Bristot de Oliveira <bristot@...hat.com>, Valentin Schneider <vschneid@...hat.com>, <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH] sched/fair: Choose the CPU where short task is running during wake up On 2022-09-15 at 10:10:25 -0700, Tim Chen wrote: > On Fri, 2022-09-16 at 00:54 +0800, Chen Yu wrote: > > > > +/* > > + * If a task switches in and then voluntarily relinquishes the > > + * CPU quickly, it is regarded as a short running task. > > + * sysctl_sched_min_granularity is chosen as the threshold, > > + * as this value is the minimal slice if there are too many > > + * runnable tasks, see __sched_period(). > > + */ > > +static int is_short_task(struct task_struct *p) > > +{ > > + return (p->se.sum_exec_runtime <= > > + (p->nvcsw * sysctl_sched_min_granularity)); > > +} > > + > > /* > > * The purpose of wake_affine() is to quickly determine on which CPU we can run > > * soonest. For the purpose of speed we only consider the waking and previous > > @@ -6050,7 +6063,8 @@ wake_affine_idle(int this_cpu, int prev_cpu, int sync) > > if (available_idle_cpu(this_cpu) && cpus_share_cache(this_cpu, prev_cpu)) > > return available_idle_cpu(prev_cpu) ? prev_cpu : this_cpu; > > > > - if (sync && cpu_rq(this_cpu)->nr_running == 1) > > + if ((sync && cpu_rq(this_cpu)->nr_running == 1) || > > + is_short_task(cpu_curr(this_cpu))) > > return this_cpu; > > > > if (available_idle_cpu(prev_cpu)) > > @@ -6434,6 +6448,21 @@ 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. If the waker on target CPU is a short > > + * task and the wakee is also a short task, pick > > + * target directly. > > + */ > > + if (!has_idle_core && (5 * nr < 3 * sd->span_weight) && > > + is_short_task(p) && is_short_task(cpu_curr(target))) > > Should we check if target's rq's nr_running is 1, and if there's pending waking > task before picking it? > Yes we can consider the two factors, then the criteria to pick up a target CPU would be more strict. After taking nr_running and the pending wakeup request into consideration, I think it would be a variant of WF_SYNC and we can get rid of 'system should be busy' restriction. I'll do some test in this direction. thanks, Chenyu > > + return target; > > } > > } > > > > Thanks. > > Tim >
Powered by blists - more mailing lists