Thomas Gleixner <[email protected]> writes:
> On Wed, Sep 20 2023 at 17:57, Ankur Arora wrote:
>> Thomas Gleixner <[email protected]> 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
On Wed, 20 Sep 2023 21:16:17 -0700
Ankur Arora <[email protected]> wrote:
> > On Wed, Sep 20 2023 at 17:57, Ankur Arora wrote:
> >> Thomas Gleixner <[email protected]> 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.
> >
> > 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.
"It's electrifying!" ;-)
https://www.youtube.com/watch?v=7oKPYe53h78
-- Steve