linux-kernel - Re: [PATCH] sched/eevdf: Toggle eligibility through sched

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231016112851.5cc0ccad@gandalf.local.home>
Date:   Mon, 16 Oct 2023 11:28:51 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Youssef Esmat <youssefesmat@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>, bsegall@...gle.com,
        mingo@...nel.org, vincent.guittot@...aro.org,
        juri.lelli@...hat.com, dietmar.eggemann@....com, mgorman@...e.de,
        bristot@...hat.com, corbet@....net, qyousef@...alina.io,
        chris.hyser@...cle.com, patrick.bellasi@...bug.net, pjt@...gle.com,
        pavel@....cz, qperret@...gle.com, tim.c.chen@...ux.intel.com,
        joshdon@...gle.com, timj@....org, kprateek.nayak@....com,
        yu.c.chen@...el.com, joel@...lfernandes.org, efault@....de,
        tglx@...utronix.de, wuyun.abel@...edance.com
Subject: Re: [PATCH] sched/eevdf: Toggle eligibility through sched_feat

On Sun, 15 Oct 2023 12:44:28 +0200
Peter Zijlstra <peterz@...radead.org> 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