Thomas Gleixner <tglx@xxxxxxxxxxxxx> writes: > On Wed, Sep 20 2023 at 17:57, Ankur Arora wrote: >> Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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
