The following commit has been merged into the sched/core branch of tip:
Commit-ID: acb4decc1e900468d51b33c5f1ee445278e716a7
Gitweb:
https://git.kernel.org/tip/acb4decc1e900468d51b33c5f1ee445278e716a7
Author:Aubrey Li
AuthorDate:Wed, 24 Feb 2021 16:15:49 +08:00
Committer
On 2021/3/22 20:56, Peter Zijlstra wrote:
> On Mon, Mar 22, 2021 at 08:31:09PM +0800, Li, Aubrey wrote:
>> Please let me know if I put cookie match check at the right position
>> in task_hot(), if so, I'll obtain some performance data of it.
>
On 2021/3/22 20:56, Peter Zijlstra wrote:
> On Mon, Mar 22, 2021 at 08:31:09PM +0800, Li, Aubrey wrote:
>> Please let me know if I put cookie match check at the right position
>> in task_hot(), if so, I'll obtain some performance data of it.
>
ppropriate.
>
Please let me know if I put cookie match check at the right position
in task_hot(), if so, I'll obtain some performance data of it.
Thanks,
-Aubrey
===
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7f2fb
On 2021/3/22 15:48, Peter Zijlstra wrote:
> On Sun, Mar 21, 2021 at 09:34:00PM +0800, Li, Aubrey wrote:
>> Hi Peter,
>>
>> On 2021/3/20 23:34, Peter Zijlstra wrote:
>>> On Fri, Mar 19, 2021 at 04:32:48PM -0400, Joel Fernandes (Google) wrote:
>>>> @@ -753
r non-smt
machines?
Thanks,
-Aubrey
> this could contribute to up 8%+ hackbench performance loss on a
> machine like kunpeng 920 which has no smt. this patch removes the
> redundant test_idle_cores() for non-smt machines.
>
> we run the below hackbench with different -g parameter
e able to override
> it.
>
IIRC, this change can avoid the following scenario:
One sysbench cpu thread(cookieA) and sysbench mysql thread(cookieB) running
on the two siblings of core_1, the other sysbench cpu thread(cookieA) and
sysbench mysql thread(cookieB) running on the two siblings of core2, which
causes 50% force idle.
This is not an imbalance case.
Thanks,
-Aubrey
From: Aubrey Li
Add idle cpumask to track idle cpus in sched domain. Every time
a CPU enters idle, the CPU is set in idle cpumask to be a wakeup
target. And if the CPU is not in idle, the CPU is cleared in idle
cpumask during scheduler tick to ratelimit idle cpumask update.
When a task wakes up
On 2021/2/24 16:15, Aubrey Li wrote:
> A long-tail load balance cost is observed on the newly idle path,
> this is caused by a race window between the first nr_running check
> of the busiest runqueue and its nr_running recheck in detach_tasks.
>
> Before the busiest runqueue is lo
From: Aubrey Li
Add idle cpumask to track idle cpus in sched domain. Every time
a CPU enters idle, the CPU is set in idle cpumask to be a wakeup
target. And if the CPU is not in idle, the CPU is cleared in idle
cpumask during scheduler tick to ratelimit idle cpumask update.
When a task wakes up
From: Aubrey Li
Scanning idle cpu from the idle cpumask avoid superfluous scans
of the LLC domain, as the first bit in the idle cpumask is the
target. Considering the selected target could become busy, the
idle check is reserved, but SIS_PROP feature becomes meaningless,
so remove avg_scan_cost
On 2021/3/8 19:30, Vincent Guittot wrote:
> Hi Aubrey,
>
> On Thu, 4 Mar 2021 at 14:51, Li, Aubrey wrote:
>>
>> Hi Peter,
>>
>> On 2020/12/11 23:07, Vincent Guittot wrote:
>>> On Thu, 10 Dec 2020 at 02:44, Aubrey Li wrote:
>>>>
>>&
Hi Peter,
On 2020/12/11 23:07, Vincent Guittot wrote:
> On Thu, 10 Dec 2020 at 02:44, Aubrey Li wrote:
>>
>> Add idle cpumask to track idle cpus in sched domain. Every time
>> a CPU enters idle, the CPU is set in idle cpumask to be a wakeup
>> target. And if the CPU
: Srinivas Pandruvada
Cc: Rafael J. Wysocki
Signed-off-by: Aubrey Li
---
kernel/sched/fair.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 04a3ce2..5c67804 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7675,6
On 2021/2/24 1:33, Vincent Guittot wrote:
> On Tue, 23 Feb 2021 at 06:41, Li, Aubrey wrote:
>>
>> Hi Vincent,
>>
>> Sorry for the delay, I just returned from Chinese New Year holiday.
>>
>> On 2021/1/25 22:51, Vincent Guittot wrote:
>>>
Hi Vincent,
Sorry for the delay, I just returned from Chinese New Year holiday.
On 2021/1/25 22:51, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 15:00, Li, Aubrey wrote:
>>
>> On 2021/1/25 18:56, Vincent Guittot wrote:
>>> On Mon, 25 Jan 2021 at 06:50, Aubrey Li wrot
latency
==
mthread base%stdv4 %std
25% 1 2.89 0.9884 7.34
50% 1 40.38 1.0055 38.37
75% 1 4.761.0095 4.62
100%1 10.09 1.0083 8.03
Thanks,
-Aubrey
On 2021/1/25 22:51, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 15:00, Li, Aubrey wrote:
>>
>> On 2021/1/25 18:56, Vincent Guittot wrote:
>>> On Mon, 25 Jan 2021 at 06:50, Aubrey Li wrote:
>>>>
>>>> A long-tail load balance cost is observed
On 2021/1/25 18:56, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 06:50, Aubrey Li wrote:
>>
>> A long-tail load balance cost is observed on the newly idle path,
>> this is caused by a race window between the first nr_running check
>> of the busiest runqueue an
On 2021/1/25 17:04, Mel Gorman wrote:
> On Mon, Jan 25, 2021 at 12:29:47PM +0800, Li, Aubrey wrote:
>>>>> hackbench -l 2560 -g 1 on 8 cores arm64
>>>>> v5.11-rc4 : 1.355 (+/- 7.96)
>>>>> + sis improvement : 1.923 (+/- 25%)
>>>>> + the
On 2021/1/25 17:06, Mel Gorman wrote:
> On Mon, Jan 25, 2021 at 02:02:58PM +0800, Aubrey Li wrote:
>> A long-tail load balance cost is observed on the newly idle path,
>> this is caused by a race window between the first nr_running check
>> of the busiest runqueue and its
.
Cc: Andi Kleen
Cc: Tim Chen
Cc: Srinivas Pandruvada
Cc: Rafael J. Wysocki
Signed-off-by: Aubrey Li
---
kernel/sched/fair.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ae7ceba..b59f371 100644
--- a/kernel/sched
On 2021/1/22 21:22, Vincent Guittot wrote:
> On Fri, 22 Jan 2021 at 11:14, Mel Gorman wrote:
>>
>> On Fri, Jan 22, 2021 at 10:30:52AM +0100, Vincent Guittot wrote:
>>> Hi Mel,
>>>
>>> On Tue, 19 Jan 2021 at 13:02, Mel Gorman
>>> wrote:
On Tue, Jan 19, 2021 at 12:33:04PM +0100, Vincent
On 2021/1/15 18:08, Mel Gorman wrote:
> From: Peter Zijlstra (Intel)
>
> Both select_idle_core() and select_idle_cpu() do a loop over the same
> cpumask. Observe that by clearing the already visited CPUs, we can
> fold the iteration and iterate a core at a time.
>
> All we need to do is remember
*sd, int t
> avg_cost = this_sd->avg_scan_cost + 1;
>
> span_avg = sd->span_weight * avg_idle;
> - if (span_avg > 4*avg_cost)
> + if (span_avg > sis_min_cores*avg_cost)
> nr = div_u64(span_avg, avg_cost);
> else
> - nr = 4;
> + nr = sis_min_cores;
> +
> + nr *= sched_smt_weight;
Is it better to put this into an inline wrapper to hide sched_smt_weight if
!CONFIG_SCHED_SMT?
Thanks,
-Aubrey
Change hierachy to hierarchy and congifured to configured, no functionality
changed.
Signed-off-by: Aubrey Li
---
kernel/cgroup/cpuset.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 57b5b5d..15f4300 100644
--- a
9.520.9503 5.35
240 1 8.550.9657 3.34
It looks like
- hackbench has a significant improvement of 4 groups
- uperf has a significant regression of 240 threads
Please let me know if you have any interested cases I can run/rerun.
Thanks,
-Aubrey
Hi Bao Hua,
Sorry I almost missed this message, :(
On 2020/12/14 7:29, Song Bao Hua (Barry Song) wrote:
>
> Hi Aubrey,
>
> The patch looks great. But I didn't find any hackbench improvement
> on kunpeng 920 which has 24 cores for each llc span. Llc span is also
> one num
On 2020/12/15 15:59, Peter Zijlstra wrote:
> On Tue, Dec 15, 2020 at 11:36:35AM +0800, Li, Aubrey wrote:
>> On 2020/12/15 0:48, Peter Zijlstra wrote:
>>> We compute the average cost of the total scan, but then use it as a
>>> per-cpu scan cost when computing the s
it
faster when the load is very high.
Thanks,
-Aubrey
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> kernel/sched/fair.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6144,10 +61
On 2020/12/10 19:34, Mel Gorman wrote:
> On Thu, Dec 10, 2020 at 04:23:47PM +0800, Li, Aubrey wrote:
>>> I ran this patch with tbench on top of of the schedstat patches that
>>> track SIS efficiency. The tracking adds overhead so it's not a perfect
>>> perform
On 2020/12/11 23:22, Vincent Guittot wrote:
> On Fri, 11 Dec 2020 at 16:19, Li, Aubrey wrote:
>>
>> On 2020/12/11 23:07, Vincent Guittot wrote:
>>> On Thu, 10 Dec 2020 at 02:44, Aubrey Li wrote:
>>>>
>>>> Add idle cpumask to track idle cpus in sche
On 2020/12/11 23:07, Vincent Guittot wrote:
> On Thu, 10 Dec 2020 at 02:44, Aubrey Li wrote:
>>
>> Add idle cpumask to track idle cpus in sched domain. Every time
>> a CPU enters idle, the CPU is set in idle cpumask to be a wakeup
>> target. And if the CPU is not in
On 2020/12/10 19:34, Mel Gorman wrote:
> On Thu, Dec 10, 2020 at 04:23:47PM +0800, Li, Aubrey wrote:
>>> I ran this patch with tbench on top of of the schedstat patches that
>>> track SIS efficiency. The tracking adds overhead so it's not a perfect
>>> perform
Hi Mel,
On 2020/12/9 22:36, Mel Gorman wrote:
> On Wed, Dec 09, 2020 at 02:24:04PM +0800, Aubrey Li wrote:
>> Add idle cpumask to track idle cpus in sched domain. Every time
>> a CPU enters idle, the CPU is set in idle cpumask to be a wakeup
>> target. And if the CPU is no
t; return -1;
I thought about this again and here seems not to be consistent:
- even if nr reduces to 0, shouldn't avg_scan_cost be updated as well before
return -1?
- if avg_scan_cost is not updated because nr is throttled, the first
time = cpu_clock(this);
can be optimized. As nr is calculated and we already know which of the weight
of cpumask and nr is greater.
Thanks,
-Aubrey
ter Zijlstra
Cc: Mel Gorman
Cc: Vincent Guittot
Cc: Qais Yousef
Cc: Valentin Schneider
Cc: Jiang Biao
Cc: Tim Chen
Signed-off-by: Aubrey Li
---
include/linux/sched/topology.h | 13 ++
kernel/sched/core.c| 2 ++
kernel/sched/fair.c| 45 +
On 2020/12/9 21:09, Vincent Guittot wrote:
> On Wed, 9 Dec 2020 at 11:58, Li, Aubrey wrote:
>>
>> On 2020/12/9 16:15, Vincent Guittot wrote:
>>> Le mercredi 09 déc. 2020 à 14:24:04 (+0800), Aubrey Li a écrit :
>>>> Add idle cpumask to track idle cpus in sched
On 2020/12/9 17:05, Mel Gorman wrote:
> On Wed, Dec 09, 2020 at 01:28:11PM +0800, Li, Aubrey wrote:
>>>> nr = div_u64(span_avg, avg_cost);
>>>> else
>>>> nr = 4;
>>>>
On 2020/12/9 16:15, Vincent Guittot wrote:
> Le mercredi 09 déc. 2020 à 14:24:04 (+0800), Aubrey Li a écrit :
>> Add idle cpumask to track idle cpus in sched domain. Every time
>> a CPU enters idle, the CPU is set in idle cpumask to be a wakeup
>> target. And if the CPU is no
v1->v2:
- idle cpumask is updated in the nohz routines, by initializing idle
cpumask with sched_domain_span(sd), nohz=off case remains the original
behavior.
Cc: Peter Zijlstra
Cc: Mel Gorman
Cc: Vincent Guittot
Cc: Qais Yousef
Cc: Valentin Schneider
Cc: Jiang Biao
Cc: Tim Chen
Signed
else
>> nr = 4;
>> - }
>> -
>> - time = cpu_clock(this);
>>
>> - cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
>> + time = cpu_clock(this);
>> + }
>>
>> for_each_cpu_wrap(cpu, cpus, target) {
>> if (!--nr)
nr is the key of this throttling mechanism, need to be placed under
sched_feat(SIS_PROP) as well.
Thanks,
-Aubrey
Hi Peter,
Thanks for the comments.
On 2020/12/8 22:16, Peter Zijlstra wrote:
> On Tue, Dec 08, 2020 at 09:49:57AM +0800, Aubrey Li wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index c4da7e17b906..b8af602dea79 100644
>> --- a/kernel/sched/core.c
>>
Vincent's
suggestion to decouple idle cpumask update from stop_tick signal, that is, the
CPU is set in idle cpumask every time the CPU enters idle, this should address
Peter's concern about the facebook trail-latency workload, as I didn't see
any regression in schbench workload 99.th latency report.
However, I also didn't see any significant benefit so far, probably I should
put more load on the system. I'll do more characterization of uperf workload
to see if I can find anything.
Thanks,
-Aubrey
hz routines, by initializing idle
cpumask with sched_domain_span(sd), nohz=off case remains the original
behavior.
Cc: Mel Gorman
Cc: Vincent Guittot
Cc: Qais Yousef
Cc: Valentin Schneider
Cc: Jiang Biao
Cc: Tim Chen
Signed-off-by: Aubrey Li
---
include/linux/sched/topology.h | 13 +
kern
On 2020/12/4 21:47, Vincent Guittot wrote:
> On Fri, 4 Dec 2020 at 14:40, Li, Aubrey wrote:
>>
>> On 2020/12/4 21:17, Vincent Guittot wrote:
>>> On Fri, 4 Dec 2020 at 14:13, Vincent Guittot
>>> wrote:
>>>>
>>>> On Fri, 4 Dec 2020 at 1
On 2020/12/4 21:40, Li, Aubrey wrote:
> On 2020/12/4 21:17, Vincent Guittot wrote:
>> On Fri, 4 Dec 2020 at 14:13, Vincent Guittot
>> wrote:
>>>
>>> On Fri, 4 Dec 2020 at 12:30, Mel Gorman wrote:
>>>>
>>>> On Fri, Dec 04, 2020 at 11:56
> target in select_idle_core because it will not help to find an idle
>> core. The sibling cpus will then be check either by select_idle_cpu
>> of select_idle_smt
>
> also, while looping the cpumask, the sibling cpus of not idle cpu are
> removed and will not be check
>
IIUC, select_idle_core and select_idle_cpu share the same
cpumask(select_idle_mask)?
If the target's sibling is removed from select_idle_mask from
select_idle_core(),
select_idle_cpu() will lose the chance to pick it up?
Thanks,
-Aubrey
On 2020/12/2 22:09, Li, Aubrey wrote:
> Hi Balbir,
>
> I still placed the patch embedded in this thread, welcome any comments.
Sorry, this version needs more work, refined as below, and I realized
I should place a version number to the patch, start from v2 now.
Thanks
Hi Mel,
On 2020/11/26 20:13, Mel Gorman wrote:
> On Thu, Nov 26, 2020 at 02:57:07PM +0800, Li, Aubrey wrote:
>> Hi Robot,
>>
>> On 2020/11/25 17:09, kernel test robot wrote:
>>> Greeting,
>>>
>>> FYI, we noticed a -29.5% regression of netperf.
Hi Balbir,
I still placed the patch embedded in this thread, welcome any comments.
Thanks,
-Aubrey
==
>From d64455dcaf47329673903a68a9df1151400cdd7a Mon Sep 17 00:00:00 2001
From: Aubrey Li
Date: Wed, 2 Dec 2020 13:53:30 +0
On 2020/11/30 22:47, Vincent Guittot wrote:
> On Mon, 30 Nov 2020 at 15:40, Mel Gorman wrote:
>>
>> The clearing of SMT siblings from the SIS mask before checking for an idle
>> core is a small but unnecessary cost. Defer the clearing of the siblings
>> until the scan moves to the next potential t
On 2020/11/30 18:35, Vincent Guittot wrote:
> On Wed, 18 Nov 2020 at 00:20, Joel Fernandes (Google)
> wrote:
>>
>> From: Aubrey Li
>>
>> - Don't migrate if there is a cookie mismatch
>> Load balance tries to move task from busiest CPU to the
>>
On 2020/11/30 17:33, Balbir Singh wrote:
> On Thu, Nov 26, 2020 at 05:26:31PM +0800, Li, Aubrey wrote:
>> On 2020/11/26 16:32, Balbir Singh wrote:
>>> On Thu, Nov 26, 2020 at 11:20:41AM +0800, Li, Aubrey wrote:
>>>> On 2020/11/26 6:57, Balbir Singh wrote:
>>&g
On 2020/11/26 16:14, Vincent Guittot wrote:
> On Wed, 25 Nov 2020 at 14:37, Li, Aubrey wrote:
>>
>> On 2020/11/25 16:31, Vincent Guittot wrote:
>>> On Wed, 25 Nov 2020 at 03:03, Li, Aubrey wrote:
>>>>
>>>> On 2020/11/25 1:01, Vincent Guittot wro
On 2020/11/26 16:32, Balbir Singh wrote:
> On Thu, Nov 26, 2020 at 11:20:41AM +0800, Li, Aubrey wrote:
>> On 2020/11/26 6:57, Balbir Singh wrote:
>>> On Wed, Nov 25, 2020 at 11:12:53AM +0800, Li, Aubrey wrote:
>>>> On 2020/11/24 23:42, Peter Zijlstra wrote:
>>&g
On 2020/11/26 6:57, Balbir Singh wrote:
> On Wed, Nov 25, 2020 at 11:12:53AM +0800, Li, Aubrey wrote:
>> On 2020/11/24 23:42, Peter Zijlstra wrote:
>>> On Mon, Nov 23, 2020 at 12:36:10PM +0800, Li, Aubrey wrote:
>>>&g
On 2020/11/25 16:31, Vincent Guittot wrote:
> On Wed, 25 Nov 2020 at 03:03, Li, Aubrey wrote:
>>
>> On 2020/11/25 1:01, Vincent Guittot wrote:
>>> Hi Aubrey,
>>>
>>> Le mardi 24 nov. 2020 à 15:01:38 (+0800), Li, Aubrey a écrit :
>>>> Hi V
On 2020/11/24 23:42, Peter Zijlstra wrote:
> On Mon, Nov 23, 2020 at 12:36:10PM +0800, Li, Aubrey wrote:
>>>> +#ifdef CONFIG_SCHED_CORE
>>>> + /*
>>>> + * Skip this cpu if source task's cookie does not mat
On 2020/11/25 1:01, Vincent Guittot wrote:
> Hi Aubrey,
>
> Le mardi 24 nov. 2020 à 15:01:38 (+0800), Li, Aubrey a écrit :
>> Hi Vincent,
>>
>> On 2020/11/23 17:27, Vincent Guittot wrote:
>>> Hi Aubrey,
>>>
>>> On Thu, 19 Nov 2020 at 13:15,
Hi Vincent,
On 2020/11/23 17:27, Vincent Guittot wrote:
> Hi Aubrey,
>
> On Thu, 19 Nov 2020 at 13:15, Aubrey Li wrote:
>>
>> Add idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, if the idle driver indicates to stop tick, this CPU
>> i
On 2020/11/24 7:35, Balbir Singh wrote:
> On Mon, Nov 23, 2020 at 11:07:27PM +0800, Li, Aubrey wrote:
>> On 2020/11/23 12:38, Balbir Singh wrote:
>>> On Tue, Nov 17, 2020 at 06:19:43PM -0500, Joel Fernandes (Google) wrote:
>>>> From: Peter Zijlstra
>>>>
&
m keeping jumping among the cores forever.
For example, on a SMT2 platform:
- core0 runs taskA and taskB, core_occupation is 2
- core1 runs taskC, core_occupation is 1
Without this check, taskB could ping-pong between core0 and core1 by core load
balance.
Thanks,
-Aubrey
On 2020/11/23 7:54, Balbir Singh wrote:
> On Tue, Nov 17, 2020 at 06:19:44PM -0500, Joel Fernandes (Google) wrote:
>> From: Aubrey Li
>>
>> - Don't migrate if there is a cookie mismatch
>> Load balance tries to move task from busiest CPU to the
>>
d), nohz=off case remains the original
behavior.
Cc: Mel Gorman
Cc: Vincent Guittot
Cc: Qais Yousef
Cc: Valentin Schneider
Cc: Jiang Biao
Cc: Tim Chen
Signed-off-by: Aubrey Li
---
include/linux/sched/topology.h | 13 +
kernel/sched/core.c| 2 ++
kernel/sched/fair.c
On 2020/11/19 16:19, Vincent Guittot wrote:
> On Thu, 19 Nov 2020 at 02:34, Li, Aubrey wrote:
>>
>> Hi Vincent,
>>
>> On 2020/11/18 21:36, Vincent Guittot wrote:
>>> On Wed, 18 Nov 2020 at 04:48, Aubrey Li wrote:
>>>>
>>>> From: Aubre
Hi Vincent,
On 2020/11/18 21:36, Vincent Guittot wrote:
> On Wed, 18 Nov 2020 at 04:48, Aubrey Li wrote:
>>
>> From: Aubrey Li
>>
>> Add idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, if the idle driver indicates to stop tick, this
On 2020/11/18 20:06, Valentin Schneider wrote:
>
> On 16/11/20 20:04, Aubrey Li wrote:
>> From: Aubrey Li
>>
>> Add idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, if the idle driver indicates to stop tick, this CPU
>> is set in th
From: Aubrey Li
Add idle cpumask to track idle cpus in sched domain. When a CPU
enters idle, if the idle driver indicates to stop tick, this CPU
is set in the idle cpumask to be a wakeup target. And if the CPU
is not in idle, the CPU is cleared in idle cpumask during scheduler
tick to ratelimit
On 2020/11/12 18:57, Qais Yousef wrote:
> On 10/21/20 23:03, Aubrey Li wrote:
>> From: Aubrey Li
>>
>> Added idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, its corresponding bit in the idle cpumask will be set,
>> and when the CPU ex
On 2020/11/9 23:54, Valentin Schneider wrote:
>
> On 09/11/20 13:40, Li, Aubrey wrote:
>> On 2020/11/7 5:20, Valentin Schneider wrote:
>>>
>>> On 21/10/20 16:03, Aubrey Li wrote:
>>>> From: Aubrey Li
>>>>
>>>> Added idle cpuma
On 2020/11/7 5:20, Valentin Schneider wrote:
>
> On 21/10/20 16:03, Aubrey Li wrote:
>> From: Aubrey Li
>>
>> Added idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, its corresponding bit in the idle cpumask will be set,
>> and when
On 2020/11/6 15:58, Vincent Guittot wrote:
> On Wed, 21 Oct 2020 at 17:05, Aubrey Li wrote:
>>
>> From: Aubrey Li
>>
>> Added idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, its corresponding bit in the idle cpumask will be set,
>&g
On 2020/11/7 1:54, Joel Fernandes wrote:
> On Fri, Nov 06, 2020 at 10:58:58AM +0800, Li, Aubrey wrote:
>
>>>
>>> -- workload D, new added syscall workload, p
ions waittime-min waittime-max
waittime-total waittime-avgacq-bounces acquisitions holdtime-min
holdtime-max holdtime-total holdtime-avg
&rq->__lock: 210210 0.10 3.04
180.87 0.86797 79165021 0.03
20.6960650198.34 0.77
But when coresched on, they are actually one same lock, lock stat(1 second
delta) below:
class namecon-bouncescontentions waittime-min waittime-max
waittime-total waittime-avgacq-bounces acquisitions holdtime-min
holdtime-max holdtime-total holdtime-avg
&rq->__lock: 64794596484857 0.05 216.46
60829776.85 9.388346319 15399739 0.03
95.5681119515.38 5.27
This nature of core scheduling may degrade the performance of similar workloads
with frequent context switching.
Any thoughts?
Thanks,
-Aubrey
Hi Valentin,
Thanks for your reply.
On 2020/11/4 3:27, Valentin Schneider wrote:
>
> Hi,
>
> On 21/10/20 16:03, Aubrey Li wrote:
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 6b3b59cc51d6..088d1995594f 100644
>> --- a/kernel/sched/fair.
% idle%
cpu53 25.24 0.000.00% 3.88% 70.87%
Signed-off-by: Aubrey Li
---
fs/proc/stat.c | 48 +
include/linux/kernel_stat.h | 1 +
include/linux/tick.h| 2 ++
kernel/time/tick-sched.c| 48
On 2020/10/26 17:01, Peter Zijlstra wrote:
> On Sat, Oct 24, 2020 at 08:27:16AM -0400, Vineeth Pillai wrote:
>>
>>
>> On 10/24/20 7:10 AM, Vineeth Pillai wrote:
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 93a3b874077d..4cae5ac48b60 100644
>>> --- a/kernel/sched/fair.c
>
On 2020/10/20 9:43, Joel Fernandes (Google) wrote:
> core.c is already huge. The core-tagging interface code is largely
> independent of it. Move it to its own file to make both files easier to
> maintain.
>
> Tested-by: Julien Desfossez
> Signed-off-by: Joel Fernandes (Google)
> ---
> kernel/s
On 2020/10/24 20:27, Vineeth Pillai wrote:
>
>
> On 10/24/20 7:10 AM, Vineeth Pillai wrote:
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 93a3b874077d..4cae5ac48b60 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -4428,12 +4428,14 @@ pick_next_entity
On 2020/10/24 5:47, Joel Fernandes wrote:
> On Fri, Oct 23, 2020 at 01:25:38PM +0800, Li, Aubrey wrote:
>>>>> @@ -2517,6 +2528,7 @@ const struct sched_class dl_sched_class
>>>>>
>>>>> #ifdef CONFIG_SMP
>>>>>
On 2020/10/22 23:25, Joel Fernandes wrote:
> On Thu, Oct 22, 2020 at 12:59 AM Li, Aubrey wrote:
>>
>> On 2020/10/20 9:43, Joel Fernandes (Google) wrote:
>>> From: Peter Zijlstra
>>>
>>> Because sched_class::pick_next_task() also implies
>
On 2020/10/20 9:43, Joel Fernandes (Google) wrote:
> From: Peter Zijlstra
>
> Because sched_class::pick_next_task() also implies
> sched_class::set_next_task() (and possibly put_prev_task() and
> newidle_balance) it is not state invariant. This makes it unsuitable
> for remote task selection.
>
data to either host or guest attackers. For L1TF, it is possible to leak
> to guest attackers. There is no possible mitigation involving flushing
> of buffers to avoid this since the execution of attacker and victims
> happen concurrently on 2 or more HTs.
>
> Cc: Julien Desfossez
From: Aubrey Li
Added idle cpumask to track idle cpus in sched domain. When a CPU
enters idle, its corresponding bit in the idle cpumask will be set,
and when the CPU exits idle, its bit will be cleared.
When a task wakes up to select an idle cpu, scanning idle cpumask
has low cost than
On 2020/9/26 0:45, Vincent Guittot wrote:
> Le vendredi 25 sept. 2020 à 17:21:46 (+0800), Li, Aubrey a écrit :
>> Hi Vicent,
>>
>> On 2020/9/24 21:09, Vincent Guittot wrote:
>>>>>>
>>>>>> Would you mind share uperf(netperf load) result on y
(cpus, sched_domain_span(sd), p->cpus_ptr);
+ cpumask_and(cpus, sds_idle_cpus(sd->shared), p->cpus_ptr);
I just wonder if it's caused by the atomic ops as you have two cache domains
with
sd_llc(?). Do you have a x86 machine to make a comparison? It's hard for me to
find
an ARM machine but I'll try.
Also, for uperf(task thread num = cpu num) workload, how is it on patch v2? no
any
performance impact?
Thanks,
-Aubrey
On 2020/9/16 19:00, Mel Gorman wrote:
> On Wed, Sep 16, 2020 at 12:31:03PM +0800, Aubrey Li wrote:
>> Added idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, its corresponding bit in the idle cpumask will be set,
>> and when the CPU exits idle, it
On 2020/9/17 4:53, chris hyser wrote:
> On 9/16/20 10:24 AM, chris hyser wrote:
>> On 9/16/20 8:57 AM, Li, Aubrey wrote:
>>>> Here are the uperf results of the various patchsets. Note, that disabling
>>>> smt is better for these tests and that that presumably re
is updated in the nohz routines, by initializing idle
cpumask with sched_domain_span(sd), nohz=off case remains the original
behavior.
Cc: Qais Yousef
Cc: Valentin Schneider
Cc: Jiang Biao
Cc: Tim Chen
Signed-off-by: Aubrey Li
---
include/linux/sched/topology.h | 13 +
ker
On 2020/9/15 17:23, Vincent Guittot wrote:
> On Tue, 15 Sep 2020 at 10:47, Jiang Biao wrote:
>>
>> Hi, Vincent
>>
>> On Mon, 14 Sep 2020 at 20:26, Vincent Guittot
>> wrote:
>>>
>>> On Sun, 13 Sep 2020 at 05:59, Jiang Biao wrote:
>>
On 2020/9/12 7:04, Li, Aubrey wrote:
> On 2020/9/12 0:28, Qais Yousef wrote:
>> On 09/10/20 13:42, Aubrey Li wrote:
>>> Added idle cpumask to track idle cpus in sched domain. When a CPU
>>> enters idle, its corresponding bit in the idle cpumask will be set,
>>>
On 2020/9/12 0:28, Qais Yousef wrote:
> On 09/10/20 13:42, Aubrey Li wrote:
>> Added idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, its corresponding bit in the idle cpumask will be set,
>> and when the CPU exits idle, its bit will be cleared.
&g
g
1 1
Any suggestions are highly appreciated!
Thanks,
-Aubrey
Aubrey Li (1):
sched/fair: select idle cpu from idle cpumask in sched domain
include/linux/sched/topology.h | 13 +
kernel/sched/fair.c| 4 +++-
kernel/sched/topology.c| 2 +-
3 files change
last level cache domain,
especially when the system is heavily loaded.
Signed-off-by: Aubrey Li
---
include/linux/sched/topology.h | 13 +
kernel/sched/fair.c| 4 +++-
kernel/sched/topology.c| 2 +-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a
On 2020/8/14 12:04, benbjiang(蒋彪) wrote:
>
>
>> On Aug 14, 2020, at 9:36 AM, Li, Aubrey wrote:
>>
>> On 2020/8/14 8:26, benbjiang(蒋彪) wrote:
>>>
>>>
>>>> On Aug 13, 2020, at 12:28 PM, Li, Aubrey wrote:
>>>>
>>>> On
On 2020/8/14 8:26, benbjiang(蒋彪) wrote:
>
>
>> On Aug 13, 2020, at 12:28 PM, Li, Aubrey wrote:
>>
>> On 2020/8/13 7:08, Joel Fernandes wrote:
>>> On Wed, Aug 12, 2020 at 10:01:24AM +0800, Li, Aubrey wrote:
>>>> Hi Joel,
>>>>
>
On 2020/8/13 7:08, Joel Fernandes wrote:
> On Wed, Aug 12, 2020 at 10:01:24AM +0800, Li, Aubrey wrote:
>> Hi Joel,
>>
>> On 2020/8/10 0:44, Joel Fernandes wrote:
>>> Hi Aubrey,
>>>
>>> Apologies for replying late as I was still looking into the det
Hi Joel,
On 2020/8/10 0:44, Joel Fernandes wrote:
> Hi Aubrey,
>
> Apologies for replying late as I was still looking into the details.
>
> On Wed, Aug 05, 2020 at 11:57:20AM +0800, Li, Aubrey wrote:
> [...]
>> +/*
>> + * Core scheduling policy:
>> + * - COR
On 2020/8/4 0:53, Joel Fernandes wrote:
> Hi Aubrey,
>
> On Mon, Aug 3, 2020 at 4:23 AM Li, Aubrey wrote:
>>
>> On 2020/7/1 5:32, Vineeth Remanan Pillai wrote:
>>> Sixth iteration of the Core-Scheduling feature.
>>>
>>> Core scheduling is
1 - 100 of 538 matches
Mail list logo
