Date:   Wed, 20 Sep 2023 21:16:17 -0700
From:   Ankur Arora <ankur.a.arora@...cle.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ankur Arora <ankur.a.arora@...cle.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
        akpm@...ux-foundation.org, luto@...nel.org, bp@...en8.de,
        dave.hansen@...ux.intel.com, hpa@...or.com, mingo@...hat.com,
        juri.lelli@...hat.com, vincent.guittot@...aro.org,
        willy@...radead.org, mgorman@...e.de, rostedt@...dmis.org,
        jon.grimm@....com, bharata@....com, raghavendra.kt@....com,
        boris.ostrovsky@...cle.com, konrad.wilk@...cle.com,
        jgross@...e.com, andrew.cooper3@...rix.com,
        Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED


Thomas Gleixner <tglx@...utronix.de> writes:

> On Wed, Sep 20 2023 at 17:57, Ankur Arora wrote:
>> Thomas Gleixner <tglx@...utronix.de> writes:
>>> Find below a PoC which implements that scheme. It's not even close to
>>> correct, but it builds, boots and survives lightweight testing.
>>
>> Whew, that was electric. I had barely managed to sort through some of
>> the config maze.
>> From a quick look this is pretty much how you described it.
>
> Unsurpringly I spent at least 10x the time to describe it than to hack
> it up.
>
> IOW, I had done the analysis before I offered the idea and before I
> changed a single line of code. The tools I used for that are git-grep,
> tags, paper, pencil, accrued knowledge and patience, i.e. nothing even
> close to rocket science.
>
> Converting the analysis into code was mostly a matter of brain dumping
> the analysis and adherence to accrued methodology.
>
> What's electric about that?

Hmm, so I /think/ I was going for something like electric current taking
the optimal path, with a side meaning of electrifying.

Though, I guess electron flow is a quantum mechanical, so that would
really try all possible paths, which means the analogy doesn't quite
fit.

Let me substitute greased lightning for electric :D.

> I might be missing some meaning of 'electric' which is not covered by my
> mostly Webster restricted old-school understanding of the english language :)
>
>>> I did not even try to look into time-slice enforcement, but I really want
>>> to share this for illustration and for others to experiment.
>>>
>>> This keeps all the existing mechanisms in place and introduces a new
>>> config knob in the preemption model Kconfig switch: PREEMPT_AUTO
>>>
>>> If selected it builds a CONFIG_PREEMPT kernel, which disables the
>>> cond_resched() machinery and switches the fair scheduler class to use
>>> the NEED_PREEMPT_LAZY bit by default, i.e. it should be pretty close to
>>> the preempt NONE model except that cond_resched() is a NOOP and I did
>>> not validate the time-slice enforcement. The latter should be a
>>> no-brainer to figure out and fix if required.
>>
>> Yeah, let me try this out.
>
> That's what I hoped for :)

:).

Quick update: it hasn't eaten my hard disk yet. Both the "none" and
"full" variants are stable with kbuild.

Next: time-slice validation, any fixes and then maybe alarm-clock
deployments.

And, then if you are okay with it, I'll cleanup/structure your patches
together with all the other preemption cleanups we discussed into an
RFC series.

(One thing I can't wait to measure is how many cond_resched() calls
and associated dynamic instructions do we not execute now.
Not because I think it really matters for performance -- though it might
on low IPC archs, but just it'll be a relief seeing the cond_resched()
gone for real.)

--
ankur

Powered by blists - more mailing lists