LWN: Comments on "Revisiting the kernel's preemption model, part 2"

Revisiting the kernel's preemption model, part 2

meted — Wed, 23 Oct 2024 09:34:23 +0000

> For those who weren't at Kernel Recipes last week, Thomas gave a great presentation about this work there. The recording is available on YouTube
> and complements the article nicely:
> https://www.youtube.com/live/OUhB9-v-2r8?t=2h4m45s

The link says the "video has been removed". Could you post the presentations title so, who ever is curious can search for it?

follow up?

joib — Wed, 11 Sep 2024 10:39:19 +0000

There was a presentation at the OSPM conference in June: https://www.youtube.com/watch?v=cVlT1CsRI18

follow up?

corbet — Tue, 10 Sep 2024 18:57:25 +0000

There was a version of the lazy preemption patches posted in May. Since then I've seen bits of conversation that suggest that the idea is still alive, but I'm not sure how actively it is being developed at the moment.

follow up?

meyert — Tue, 10 Sep 2024 18:49:44 +0000

I'm interested to know if this idea did make it to next or any other tree, I'm curious

Revisiting the kernel's preemption model, part 2

tglx — Thu, 05 Oct 2023 00:42:04 +0000

All of that is important, but can we please have the technical discussions on LKML instead of hand-waving here?

transparency

mathstuf — Wed, 04 Oct 2023 10:31:17 +0000

In Firefox, "Open image in new tab" from the image's context menu works well too.

transparency

bnorris — Tue, 03 Oct 2023 23:51:30 +0000

That's this, which can be opened or downloaded separately to work around the problem: https://static.lwn.net/images/2020/preempt-count.svg

Revisiting the kernel's preemption model, part 2

PaulMcKenney — Tue, 03 Oct 2023 15:21:18 +0000

On RCU, indeed! It is very important to provide the occasional quiescent state to RCU, even if there is only one runnable task on the CPU in question.

I was initially concern about nohz_full CPUs, but after more discussion with Frederic, this might actually be OK. If there is an RCU grace period in progress, RCU will restart the scheduler tick interrupt, otherwise maybe no one cares. Maybe. ;-)

Revisiting the kernel's preemption model, part 2

terminus — Tue, 03 Oct 2023 07:52:11 +0000

> So, in other words, the path to a simpler and better scheduler has been laid out, but to get there somebody else is going to have to do the work to push the job through to completion.

Working on a RFC series to do just that. Thomas' approach (obviously) works, but as always there are kinks to clean up.

cond_resched(), in particular, has accumulated a variety of functionality almost in the manner of the fleas in the poem:

"Great fleas have little fleas upon their backs to bite 'em,
And little fleas have lesser fleas, and so ad infinitum."

As you note, keeping the preempt-count takes care of much of this but there are some tricky places, in particular RCU.

Cheers
Ankur

Revisiting the kernel's preemption model, part 2

alison — Tue, 03 Oct 2023 04:44:30 +0000

> It feels like it would be possible to go a step further, and have tasks designated as latency-sensitive or
> throughput-sensitive, and have only latency-sensitive tasks preempt other tasks (and make them expend their
> time slice faster if they do).

An obvious way to perform such designations is via the deadline scheduler. The fact that deadline scheduling is scarcely mentioned in discussions like this article confirms the suspicion that it is usable only in a limited set of contexts. Perhaps deadline scheduling is really only workable for RTOSes or systems with fewer tasks, like guest OSes running on top of a hypervisor.

Revisiting the kernel's preemption model, part 2

wildea01 — Mon, 02 Oct 2023 20:47:16 +0000

For those who weren't at Kernel Recipes last week, Thomas gave a great presentation about this work there. The recording is available on YouTube and complements the article nicely:

https://www.youtube.com/live/OUhB9-v-2r8?t=2h4m45s

Revisiting the kernel's preemption model, part 2

iabervon — Mon, 02 Oct 2023 20:41:24 +0000

It feels like it would be possible to go a step further, and have tasks designated as latency-sensitive or throughput-sensitive, and have only latency-sensitive tasks preempt other tasks (and make them expend their time slice faster if they do). The system could then be configured to make tasks default to latency or throughput, but also able to give different tasks at the same priority different benefits.

Revisiting the kernel's preemption model, part 2

joib — Mon, 02 Oct 2023 19:36:22 +0000

If my reading of the thread is correct, particularly this message by Ingo Molnar: https://lwn.net/ml/linux-kernel/ZQlV5l4pbKunQJug@gmail.com/ there wouldn't even be a need for some runtime/compile time knob to select between throughput-oriented and low-latency system modes as described in the article. But rather the lazy preemption would apply only to SCHED_OTHER (and IDLE and BATCH, not that I've ever seen anything use those) tasks with identical nice values, whereas higher priority tasks would preempt ASAP. So best of both worlds, in a sense.

Revisiting the kernel's preemption model, part 2

Manifault — Mon, 02 Oct 2023 18:21:30 +0000

This is a no-brainer improvement in my book. The model we currently have where a task is considered non-preemptible by default for CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY, rather than requiring it to communicate to the scheduler when it should try (keyword "try") to avoid being preempted, is fundamentally backwards and error prone. It's why we see the never-ending stream of "add cond_resched() call to avoid hogging CPU" patches flowing by. If it's a bug if we don't have a cond_resched() somewhere that would otherwise hog a core and starve important kthreads like ksoftirqd, then let's just flip the polarity and force callers to specify when they want the scheduler to try to avoid preemption for performance reasons.

Revisiting the kernel's preemption model, part 2

josh — Mon, 02 Oct 2023 17:18:24 +0000

The diagram in the article has a transparent background, which makes it unreadable for anyone using a dark background color on LWN.