On Sat, Feb 01, 2025 at 06:06:17PM -0500, Steven Rostedt wrote: > On Sat, 1 Feb 2025 19:11:29 +0100 > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > On Sat, Feb 01, 2025 at 07:47:32AM -0500, Steven Rostedt wrote: > > > > > > > > > On February 1, 2025 6:59:06 AM EST, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > > > >I still have full hate for this approach. > > > > > > So what approach would you prefer? > > > > The one that does not rely on the preemption method -- I think I posted > > something along those line, and someone else recently reposted something > > bsaed on it. > > > > Tying things to the preemption method is absurdly bad design -- and I've > > told you that before. > > How exactly is it "bad design"? Changing the preemption method itself > changes the way applications schedule and can be very noticeable to the > applications themselves. Lazy is not the default, nor even the recommended preemption method at this time. Lazy will not ever be the only preemption method, full isn't going anywhere. Lazy only applies to fair (and whatever bpf things end up using resched_curr_lazy()). Lazy works on tick granularity, which is variable per the HZ config, and way too long for any of this nonsense. So by tying this to lazy, you get something that doesn't actually work most of the time, and when it works, it has variable and bad behaviour. So yeah, crap. This really isn't difficult to understand, and I've told you this before.
