rustland: enable preemption

[arighi]

Overview

Provide preemption capability in scx_rustland_core and use this feature in scx_rustland to improve the the responsiveness of interactive tasks.

Design

For now the design is pretty simple:

• scx_rustland_core provides a new dispatch flag RL_PREEMPT_CPU that is mapped to SCX_ENQ_PREEMPT
• scx_rustland uses this flag when dispatching tasks that are classified as "interactive", so that they can preempt other tasks before their assigned time slice expires

This implies that interactive tasks can also preempt each other, potentially causing an excessive amount of preemption events if a consistent amount of tasks is classified as "interactive". This can be improved in the future by limiting the the amount of preemption events per sec., similar to what scx_lavd is doing.

Results

Measuring the performance of the usual benchmark "playing a video game while running a parallel kernel build in background" seems to give around 2-10% boost in the fps with preemption enabled, depending on the
particular video game.

Results were obtained running a make -j32 kernel build on a AMD Ryzen 7 5800X 8-Cores 16GB RAM, while testing video games such as Baldur's Gate 3 (with a solid +10% fps), Counter Strike 2 (around +5%) and Team
Fortress 2 (+2% boost).

Moreover, some WebGL applications (such as https://webglsamples.org/aquarium/aquarium.html) seem to benefit even more with preemption enabled, providing up to a +15% fps boost.

[htejun]

LGTM. Overloading cpu field to carry flags seems a bit unnecessarily complicated tho. Adding another field wouldn't make any practical difference, right?

[multics69]

Looks great to me. Simple and elegant!

It would be worth considering the worst-case behavior: When (almost) all tasks are interactive, will they preempt each other with little actual progress? It would require some sort of rate limiting.

[arighi]

LGTM. Overloading cpu field to carry flags seems a bit unnecessarily complicated tho. Adding another field wouldn't make any practical difference, right?

I agree. Moreover, adding another u64 increases the struct from 24 bytes to 32 bytes that might be actually better in terms of cacheline usage / performance:

• before:

struct dispatched_task_ctx {
	s32                        pid;                  /*     0     4 */
	s32                        cpu;                  /*     4     4 */
	u64                        cpumask_cnt;          /*     8     8 */
	u64                        slice_ns;             /*    16     8 */

	/* size: 24, cachelines: 1, members: 4 */
	/* last cacheline: 24 bytes */
};

• after:

struct dispatched_task_ctx {
	s32                        pid;                  /*     0     4 */
	s32                        cpu;                  /*     4     4 */
	u64                        cpumask_cnt;          /*     8     8 */
	u64                        slice_ns;             /*    16     8 */
	u64                        flags;                /*    24     8 */

	/* size: 32, cachelines: 1, members: 5 */
	/* last cacheline: 32 bytes */
};

I'll change this and update the PR. Thanks!

[arighi]

Looks great to me. Simple and elegant!

It would be worth considering the worst-case behavior: When (almost) all tasks are interactive, will they preempt each other with little actual progress? It would require some sort of rate limiting.

Right, rate-limiting the RL_PREEMPT_CPU dispatches seems the easiest way to mitigate potential storms of unnecessary preempt events and it's probably good enough in practice, that's the first improvement that I'm planning to do and I'll try to re-use some of the logic from scx__lavd. :)