LinuxLists.cc - [PATCH] sched/eevdf: Toggle eligibility through sched

2023-10-13 03:02:43

Subject: [PATCH] sched/eevdf: Toggle eligibility through sched_feat

Interactive workloads see performance gains by disabling eligibility
checks (EEVDF->EVDF). Disabling the checks reduces the number of
context switches and delays less important work (higher deadlines/nice
values) in favor of more important work (lower deadlines/nice values).

That said, that can add large latencies for some work loads and as the
default is eligibility on, but allowing it to be turned off when
beneficial.

Signed-off-by: Youssef Esmat <[email protected]>
Link: https://lore.kernel.org/lkml/CA+q576MS0-MV1Oy-eecvmYpvNT3tqxD8syzrpxQ-Zk310hvRbw@mail.gmail.com/
---
kernel/sched/fair.c | 3 +++
kernel/sched/features.h | 1 +
2 files changed, 4 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a751e552f253..16106da5a354 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -728,6 +728,9 @@ int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se)
s64 avg = cfs_rq->avg_vruntime;
long load = cfs_rq->avg_load;

+ if (!sched_feat(ENFORCE_ELIGIBILITY))
+ return 1;
+
if (curr && curr->on_rq) {
unsigned long weight = scale_load_down(curr->load.weight);

diff --git a/kernel/sched/features.h b/kernel/sched/features.h
index f770168230ae..84e38a0045b7 100644
--- a/kernel/sched/features.h
+++ b/kernel/sched/features.h
@@ -7,6 +7,7 @@
SCHED_FEAT(PLACE_LAG, true)
SCHED_FEAT(PLACE_DEADLINE_INITIAL, true)
SCHED_FEAT(RUN_TO_PARITY, true)
+SCHED_FEAT(ENFORCE_ELIGIBILITY, true)

/*
* Prefer to schedule the task we woke last (assuming it failed
--
2.42.0.655.g421f12c284-goog

2023-10-13 06:52:59

by Mike Galbraith

[permalink] [raw]

Subject: Re: [PATCH] sched/eevdf: Toggle eligibility through sched_feat

2023-10-15 10:55:15

by Peter Zijlstra

[permalink] [raw]

Subject: Re: [PATCH] sched/eevdf: Toggle eligibility through sched_feat

On Thu, Oct 12, 2023 at 10:02:13PM -0500, Youssef Esmat wrote:
> Interactive workloads see performance gains by disabling eligibility
> checks (EEVDF->EVDF). Disabling the checks reduces the number of
> context switches and delays less important work (higher deadlines/nice
> values) in favor of more important work (lower deadlines/nice values).
>
> That said, that can add large latencies for some work loads and as the
> default is eligibility on, but allowing it to be turned off when
> beneficial.
>
> Signed-off-by: Youssef Esmat <[email protected]>
> Link: https://lore.kernel.org/lkml/CA+q576MS0-MV1Oy-eecvmYpvNT3tqxD8syzrpxQ-Zk310hvRbw@mail.gmail.com/
> ---
> kernel/sched/fair.c | 3 +++
> kernel/sched/features.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index a751e552f253..16106da5a354 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -728,6 +728,9 @@ int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se)
> s64 avg = cfs_rq->avg_vruntime;
> long load = cfs_rq->avg_load;
>
> + if (!sched_feat(ENFORCE_ELIGIBILITY))
> + return 1;
> +
> if (curr && curr->on_rq) {
> unsigned long weight = scale_load_down(curr->load.weight);
>

Right.. could you pretty please try:

git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/eevdf

as of yesterday or so.

It defaults to (EEVDF relevant features):

SCHED_FEAT(PLACE_LAG, true)
SCHED_FEAT(PLACE_DEADLINE_INITIAL, true)
SCHED_FEAT(PREEMPT_SHORT, true)
SCHED_FEAT(PLACE_SLEEPER, false)
SCHED_FEAT(GENTLE_SLEEPER, true)
SCHED_FEAT(EVDF, false)
SCHED_FEAT(DELAY_DEQUEUE, true)
SCHED_FEAT(GENTLE_DELAY, true)

If that doesn't do well enough, could you please try, in order of
preference:

2) NO_GENTLE_DELAY
3) NO_DELAY_DEQUEUE, PLACE_SLEEPER
4) NO_DELAY_DEQUEUE, PLACE_SLEEPER, NO_GENTLE_SLEEPER

I really don't like the EVDF option, and I think you'll end up
regretting using it sooner rather than later, just to make this one
benchmark you have happy.

I'm hoping the default is enough, but otherwise any of the above should
be a *much* better scheduler.

Also, bonus points if you can create us a stand alone benchmark that
captures your metric (al-la facebook's schbench) without the whole
chrome nonsense, that'd be epic.

2023-10-16 13:34:50

by Tor Vic

[permalink] [raw]

Subject: Re: [PATCH] sched/eevdf: Toggle eligibility through sched_feat

On 10/15/23 12:44, Peter Zijlstra wrote:
> On Thu, Oct 12, 2023 at 10:02:13PM -0500, Youssef Esmat wrote:
>> Interactive workloads see performance gains by disabling eligibility
>> checks (EEVDF->EVDF). Disabling the checks reduces the number of
>> context switches and delays less important work (higher deadlines/nice
>> values) in favor of more important work (lower deadlines/nice values).
>>
>> That said, that can add large latencies for some work loads and as the
>> default is eligibility on, but allowing it to be turned off when
>> beneficial.
>>
>> Signed-off-by: Youssef Esmat <[email protected]>
>> Link: https://lore.kernel.org/lkml/CA+q576MS0-MV1Oy-eecvmYpvNT3tqxD8syzrpxQ-Zk310hvRbw@mail.gmail.com/
>> ---
>> kernel/sched/fair.c | 3 +++
>> kernel/sched/features.h | 1 +
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index a751e552f253..16106da5a354 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -728,6 +728,9 @@ int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se)
>> s64 avg = cfs_rq->avg_vruntime;
>> long load = cfs_rq->avg_load;
>>
>> + if (!sched_feat(ENFORCE_ELIGIBILITY))
>> + return 1;
>> +
>> if (curr && curr->on_rq) {
>> unsigned long weight = scale_load_down(curr->load.weight);
>>
>
> Right.. could you pretty please try:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/eevdf
>
> as of yesterday or so.
>
> It defaults to (EEVDF relevant features):
>
> SCHED_FEAT(PLACE_LAG, true)
> SCHED_FEAT(PLACE_DEADLINE_INITIAL, true)
> SCHED_FEAT(PREEMPT_SHORT, true)
> SCHED_FEAT(PLACE_SLEEPER, false)
> SCHED_FEAT(GENTLE_SLEEPER, true)
> SCHED_FEAT(EVDF, false)
> SCHED_FEAT(DELAY_DEQUEUE, true)
> SCHED_FEAT(GENTLE_DELAY, true)
>
> If that doesn't do well enough, could you please try, in order of
> preference:
>
> 2) NO_GENTLE_DELAY
> 3) NO_DELAY_DEQUEUE, PLACE_SLEEPER
> 4) NO_DELAY_DEQUEUE, PLACE_SLEEPER, NO_GENTLE_SLEEPER

I'm very interested in this scheduler stuff, but I know nothing about
the code.

Still, I ran some very quick benchmarks on a dual-core Skylake laptop
running 6.6-rc6.
Base slice is 5 ms.

1) Without the recent patches from Peter's tree
2) With patches, default features
3) With patches, NO_GENTLE_DELAY
4) With patches, NO_DELAY_DEQUEUE + PLACE_SLEEPER
5) With patches, like 4) + NO_GENTLE_SLEEPER
6) With patches, like 5) + EVDF

$ perf stat -r 7 -e cs,migrations,cache-misses,branch-misses -- perf
bench sched messaging -g 20 -l 1000 -p

test | seconds | cs | migrations | cache miss | branch miss |
------|---------|------|------------|------------|-------------|
1) | 2,90 | 192K | 6,7K | 99M | 60M |
2) | 2,97 | 226K | 6,9K | 102M | 61M |
3) | 3,00 | 247K | 6,9K | 108M | 62M |
4) | 2,92 | 182K | 7,2K | 101M | 60M |
5) | 2,94 | 203K | 6,8K | 101M | 60M |
6) | 2,79 | 84K | 6,4K | 94M | 57M |

$ stress-ng --bsearch 2 --matrix 2 --matrix-method prod --timeout 30
--metrics-brief [results in bogo ops/s]

test | bsearch | matrix |
------|---------|--------|
1) | 392 | 588 |
2) | 512 | 688 |
3) | 512 | 663 |
4) | 512 | 688 |
5) | 511 | 686 |
6) | 510 | 655 |

--

I don't know if this info is useful enough for you scheduler people, but
I hope it helps.

Cheers,
Tor

>
> I really don't like the EVDF option, and I think you'll end up
> regretting using it sooner rather than later, just to make this one
> benchmark you have happy.
>
> I'm hoping the default is enough, but otherwise any of the above should
> be a *much* better scheduler.
>
> Also, bonus points if you can create us a stand alone benchmark that
> captures your metric (al-la facebook's schbench) without the whole
> chrome nonsense, that'd be epic.
>

2023-10-16 15:27:37

by Steven Rostedt

[permalink] [raw]

Subject: Re: [PATCH] sched/eevdf: Toggle eligibility through sched_feat

On Sun, 15 Oct 2023 12:44:28 +0200
Peter Zijlstra <[email protected]> wrote:

> Right.. could you pretty please try:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/eevdf
>
> as of yesterday or so.
>
> It defaults to (EEVDF relevant features):
>
> SCHED_FEAT(PLACE_LAG, true)
> SCHED_FEAT(PLACE_DEADLINE_INITIAL, true)
> SCHED_FEAT(PREEMPT_SHORT, true)
> SCHED_FEAT(PLACE_SLEEPER, false)
> SCHED_FEAT(GENTLE_SLEEPER, true)
> SCHED_FEAT(EVDF, false)
> SCHED_FEAT(DELAY_DEQUEUE, true)
> SCHED_FEAT(GENTLE_DELAY, true)
>
> If that doesn't do well enough, could you please try, in order of
> preference:
>
> 2) NO_GENTLE_DELAY
> 3) NO_DELAY_DEQUEUE, PLACE_SLEEPER
> 4) NO_DELAY_DEQUEUE, PLACE_SLEEPER, NO_GENTLE_SLEEPER

Thanks Peter, we'll give this a try.

>
> I really don't like the EVDF option, and I think you'll end up
> regretting using it sooner rather than later, just to make this one
> benchmark you have happy.

Note, the benchmark we use is very close to real world settings that we
care about. And if we were to go further with Youssef's feature, we would
test it by sending it out to 1% of our user base, then 2%, 5%, and so on,
with a lot more feedback analysis going on. If it were to cause any
regressions, it would likely be noticed during this process, and be able to
back out any changes.

The main point is, our testing is not around any single benchmark that we
are trying to make happy. We really are looking at what makes the user base
run better in the real world.

>
> I'm hoping the default is enough, but otherwise any of the above should
> be a *much* better scheduler.
>
> Also, bonus points if you can create us a stand alone benchmark that
> captures your metric (al-la facebook's schbench) without the whole
> chrome nonsense, that'd be epic.

As I stated above. We don't really care about any one benchmark, but our
focus is on our user base. It's not as simple as what facebook would have,
as they are server focused and have a lot more information to test with. We
are more focused on the quality of chromebooks for kids in school, which is
much more difficult to analyze ;-)

What we could do, is give you a way to have access to run our benchmarks in
our infrastructure if you want to test anything in particular. Would you be
interested in that?

-- Steve

2023-10-16 16:56:46

by Peter Zijlstra

[permalink] [raw]

Subject: Re: [PATCH] sched/eevdf: Toggle eligibility through sched_feat

On Mon, Oct 16, 2023 at 11:28:51AM -0400, Steven Rostedt wrote:

> The main point is, our testing is not around any single benchmark that we
> are trying to make happy. We really are looking at what makes the user base
> run better in the real world.

This is a key (har-har) performance indicator for you guys though, I've
seen it mentioned before (with the core-scheduling crud IIRC).

As such it would be good to capture in a stand alone program and share.