sched: Restructure task_mm_cid_work for predictability

include/linux/rseq.h static inline void rseq_preempt(struct task_struct *t) · line 65

Quoted 7 lines · Gabriele Monaco

include/linux/rseq.h +7 -0

+static inline void rseq_preempt_from_tick(struct task_struct *t)
+{
+	u64 rtime = t->se.sum_exec_runtime - t->se.prev_sum_exec_runtime;
+
+	if (rtime > RSEQ_UNPREEMPTED_THRESHOLD)
+		rseq_preempt(t);
+}

This confused me.

The goal seems to be to tickle __rseq_handle_notify_resume() so it'll end up queueing that work thing. But why do we want to set PREEMPT_BIT here?

Quoted 11 lines · Peter Zijlstra

include/linux/rseq.h static inline void rseq_preempt(struct task_struct *t) · line 65

Quoted 7 lines · Gabriele Monaco

include/linux/rseq.h +7 -0

+static inline void rseq_preempt_from_tick(struct task_struct *t)
+{
+	u64 rtime = t->se.sum_exec_runtime - t->se.prev_sum_exec_runtime;
+
+	if (rtime > RSEQ_UNPREEMPTED_THRESHOLD)
+		rseq_preempt(t);
+}

This confused me.

Quoted 3 lines

The goal seems to be to tickle __rseq_handle_notify_resume() so it'll end up queueing that work thing. But why do we want to set PREEMPT_BIT here?

In that scenario, we trigger (from tick) the fact that we may recompact the mm_cid, and thus need to update the rseq mm_cid field before returning to userspace.

Changing the value of the mm_cid field while userspace is within a rseq critical section should abort the critical section, because the rseq critical section should be able to expect the mm_cid to be invariant for the whole c.s..

Quoted 20 lines · Mathieu Desnoyers

Quoted 11 lines · Peter Zijlstra

include/linux/rseq.h static inline void rseq_preempt(struct task_struct *t) · line 65

Quoted 7 lines · Gabriele Monaco

include/linux/rseq.h +7 -0

+static inline void rseq_preempt_from_tick(struct task_struct *t)
+{
+	u64 rtime = t->se.sum_exec_runtime - t->se.prev_sum_exec_runtime;
+
+	if (rtime > RSEQ_UNPREEMPTED_THRESHOLD)
+		rseq_preempt(t);
+}

This confused me.

Quoted 3 lines

The goal seems to be to tickle __rseq_handle_notify_resume() so it'll end up queueing that work thing. But why do we want to set PREEMPT_BIT here?

In that scenario, we trigger (from tick) the fact that we may recompact the mm_cid, and thus need to update the rseq mm_cid field before returning to userspace.

Quoted 4 lines

Changing the value of the mm_cid field while userspace is within a rseq critical section should abort the critical section, because the rseq critical section should be able to expect the mm_cid to be invariant for the whole c.s..

But, if we run that compaction in a worker, what guarantees the compaction is done and mm_cid is stable, but the time this task returns to userspace again?

Quoted 21 lines · Peter Zijlstra

Quoted 20 lines · Mathieu Desnoyers

Quoted 11 lines · Peter Zijlstra

include/linux/rseq.h static inline void rseq_preempt(struct task_struct *t) · line 65

Quoted 7 lines · Gabriele Monaco

include/linux/rseq.h +7 -0

+static inline void rseq_preempt_from_tick(struct task_struct *t)
+{
+	u64 rtime = t->se.sum_exec_runtime - t->se.prev_sum_exec_runtime;
+
+	if (rtime > RSEQ_UNPREEMPTED_THRESHOLD)
+		rseq_preempt(t);
+}

This confused me.

Quoted 3 lines

The goal seems to be to tickle __rseq_handle_notify_resume() so it'll end up queueing that work thing. But why do we want to set PREEMPT_BIT here?

In that scenario, we trigger (from tick) the fact that we may recompact the mm_cid, and thus need to update the rseq mm_cid field before returning to userspace.

Quoted 8 lines

Quoted 4 lines

Changing the value of the mm_cid field while userspace is within a rseq critical section should abort the critical section, because the rseq critical section should be able to expect the mm_cid to be invariant for the whole c.s..

But, if we run that compaction in a worker, what guarantees the compaction is done and mm_cid is stable, but the time this task returns to userspace again?

So let's say we have a task which is running and not preempted by any other task on a cpu for a long time.

The idea is to have the tick do two things:

A) trigger the mm_cid recompaction,

B) trigger an update of the task's rseq->mm_cid field at some point after recompaction, so it can get a mm_cid value closer to 0.

So in its current form this patch will indeed trigger rseq_preempt() for *every tick* after the task has run for more than 100ms, which I don't think is intended. This should be fixed.

Also, doing just an rseq_preempt() is not the correct approach, as AFAIU it won't force the long running task to release the currently held mm_cid value.

I think we need something that looks like the following based on the current patch:

- rename rseq_preempt_from_tick() to rseq_tick(),

- modify rseq_tick() to ensure it calls rseq_set_notify_resume(t) rather than rseq_preempt().

- modify rseq_tick() to ensure it only calls it once every RSEQ_UNPREEMPTED_THRESHOLD, rather than every tick after RSEQ_UNPREEMPTED_THRESHOLD.

- modify rseq_tick() so at some point after the work has compacted mm_cids, we do the same things as switch_mm_cid() does, namely to release the currently held cid and get a likely smaller one (closer to 0). If the value changes, then we should trigger rseq_preempt() so the task updates the mm_cid field before returning to userspace and restarts ongoing rseq critical section.

Thoughts ?

Thanks both for the comments, I tried to implement what Mathieu suggested. This patch applies directly on 2/3 but I'm sending it here first to get feedback.

Essentially, I refactored a bit to avoid the need to add more dependencies to rseq, the rseq_tick is now called task_tick_mm_cid (as before the series) and it does the two things you mentioned:
* A) trigger the mm_cid recompaction
* B) trigger an update of the task's rseq->mm_cid field at some point after recompaction, so it can get a mm_cid value closer to 0.

Now, A occurs only after the scan time elapsed, which means it could potentially run multiple times in case the work is not scheduled before the next tick, I'm not sure adding more checks to make sure it happens once and only once really makes sense here.

kernel/sched/core.c +1 -0

+	if (t->mm && rtime > RSEQ_UNPREEMPTED_THRESHOLD) {

B is occurring after the work updates the last scan time, so we are in a condition where the runtime is above threshold but the (next) scan time did not expire yet.
I tried to account for multiple threads updating the mm_cid (not necessarily the long running one, or in case more are long running), for this I'm tracking the last time we updated the mm_cid, if that occurred before the last mm_cid scan, we need to update (and preempt).

Does this make sense to you?

Thanks,
Gabriele

Signed-off-by Gabriele Monaco <[email protected]>

---
  include/linux/rseq.h  | 14 +-------------
  include/linux/sched.h |  1 +
  kernel/sched/core.c   | 42 +++++++++++++++++++++++++++++++++++++++++-
  kernel/sched/sched.h  |  3 +++
  4 files changed, 46 insertions(+), 14 deletions(-)

include/linux/rseq.h +1 -13

index d20fd72f4c80d..7e3fa2ae9e7a4 100644
@@ -7,8 +7,6 @@
  #include <linux/preempt.h>
  #include <linux/sched.h>
 
-#define RSEQ_UNPREEMPTED_THRESHOLD	(100ULL * 1000000)	/* 100ms */
-
  /*
   * Map the event mask on the user-space ABI enum rseq_cs_flags
   * for direct mask checks.

@@ -54,14 +52,7 @@ static inline void rseq_preempt(struct task_struct *t)
  {
  	__set_bit(RSEQ_EVENT_PREEMPT_BIT, &t->rseq_event_mask);
  	rseq_set_notify_resume(t);
-}
-
-static inline void rseq_preempt_from_tick(struct task_struct *t)
-{
-	u64 rtime = t->se.sum_exec_runtime - t->se.prev_sum_exec_runtime;
-
-	if (rtime > RSEQ_UNPREEMPTED_THRESHOLD)
-		rseq_preempt(t);
+	t->last_rseq_preempt = jiffies;
  }
 
  /* rseq_migrate() requires preemption to be disabled. */

@@ -114,9 +105,6 @@ static inline void rseq_signal_deliver(struct ksignal *ksig,
  static inline void rseq_preempt(struct task_struct *t)
  {
  }
-static inline void rseq_preempt_from_tick(struct task_struct *t)
-{
-}
  static inline void rseq_migrate(struct task_struct *t)
  {
  }

include/linux/sched.h +1 -0

index 851933e62bed3..5b057095d5dc0 100644
@@ -1424,6 +1424,7 @@ struct task_struct {
  	int				last_mm_cid;	/* Most recent cid in mm */
  	int				migrate_from_cpu;
  	int				mm_cid_active;	/* Whether cid bitmap is active */
+	unsigned long			last_rseq_preempt; /* Time of last preempt in jiffies */
  #endif
 
  	struct tlbflush_unmap_batch	tlb_ubc;

kernel/sched/core.c +41 -1

index 52ad709094167..9f0c9cc284804 100644
@@ -5663,7 +5663,7 @@ void sched_tick(void)
  		resched_latency = cpu_resched_latency(rq);
  	calc_global_load_tick(rq);
  	sched_core_tick(rq);
-	rseq_preempt_from_tick(donor);
+	task_tick_mm_cid(rq, donor);
  	scx_tick(rq);
 
  	rq_unlock(rq, &rf);

@@ -10618,6 +10618,46 @@ void init_sched_mm_cid(struct task_struct *t)
  	}
  }
 
+void task_tick_mm_cid(struct rq *rq, struct task_struct *t)
+{
+	u64 rtime = t->se.sum_exec_runtime - t->se.prev_sum_exec_runtime;
+
+	/*
+	 * If a task is running unpreempted for a long time, it won't get its
+	 * mm_cid compacted and won't update its mm_cid value after a
+	 * compaction occurs.
+	 * For such a task, this function does two things:
+	 * A) trigger the mm_cid recompaction,
+	 * B) trigger an update of the task's rseq->mm_cid field at some point
+	 * after recompaction, so it can get a mm_cid value closer to 0.
+	 * A change in the mm_cid triggers an rseq_preempt.
+	 *
+	 * A occurs only after the next scan time elapsed but before the
+	 * compaction work is actually scheduled.
+	 * B occurs once after the compaction work completes, that is when scan
+	 * is no longer needed (it occurred for this mm) but the last rseq
+	 * preempt was done before the last mm_cid scan.
+	 */
+	if (t->mm && rtime > RSEQ_UNPREEMPTED_THRESHOLD) {
+		if (mm_cid_needs_scan(t->mm))
+			rseq_set_notify_resume(t);
+		else if (time_after(jiffies, t->last_rseq_preempt +
+				      msecs_to_jiffies(MM_CID_SCAN_DELAY))) {
+			int old_cid = t->mm_cid;
+
+			if (!t->mm_cid_active)
+				return;
+			mm_cid_snapshot_time(rq, t->mm);
+			mm_cid_put_lazy(t);
+			t->last_mm_cid = t->mm_cid = mm_cid_get(rq, t, t->mm);
+			if (old_cid == t->mm_cid)
+				t->last_rseq_preempt = jiffies;
+			else
+				rseq_preempt(t);
+		}
+	}
+}
+
  /* Call only when curr is a user thread. */
  void task_queue_mm_cid(struct task_struct *curr)
  {

kernel/sched/sched.h +3 -0

index 1703cd16d5433..7d104d12ed974 100644
@@ -3582,12 +3582,14 @@ extern const char *preempt_modes[];
 
  #define SCHED_MM_CID_PERIOD_NS	(100ULL * 1000000)	/* 100ms */
  #define MM_CID_SCAN_DELAY	100			/* 100ms */
+#define RSEQ_UNPREEMPTED_THRESHOLD	SCHED_MM_CID_PERIOD_NS
 
  extern raw_spinlock_t cid_lock;
  extern int use_cid_lock;
 
  extern void sched_mm_cid_migrate_from(struct task_struct *t);
  extern void sched_mm_cid_migrate_to(struct rq *dst_rq, struct task_struct *t);
+extern void task_tick_mm_cid(struct rq *rq, struct task_struct *t);
  extern void init_sched_mm_cid(struct task_struct *t);
 
  static inline void __mm_cid_put(struct mm_struct *mm, int cid)

@@ -3856,6 +3858,7 @@ static inline void switch_mm_cid(struct rq *rq,
  static inline void switch_mm_cid(struct rq *rq, struct task_struct *prev, struct task_struct *next) { }
  static inline void sched_mm_cid_migrate_from(struct task_struct *t) { }
  static inline void sched_mm_cid_migrate_to(struct rq *dst_rq, struct task_struct *t) { }
+static inline void task_tick_mm_cid(struct rq *rq, struct task_struct *t) { }
  static inline void init_sched_mm_cid(struct task_struct *t) { }
  #endif /* !CONFIG_SCHED_MM_CID */
 

base-commit: c59c19fcfad857c96effa3b2e9eb6d934d2380d8

Quoted 14 lines · Gabriele Monaco

Thanks both for the comments, I tried to implement what Mathieu suggested. This patch applies directly on 2/3 but I'm sending it here
first to get feedback.

Essentially, I refactored a bit to avoid the need to add more dependencies to rseq, the rseq_tick is now called task_tick_mm_cid (as
before the series) and it does the two things you mentioned:
  * A) trigger the mm_cid recompaction
  * B) trigger an update of the task's rseq->mm_cid field at some point
    after recompaction, so it can get a mm_cid value closer to 0.

Quoted 6 lines

Now, A occurs only after the scan time elapsed, which means it could
potentially run multiple times in case the work is not scheduled before
the next tick, I'm not sure adding more checks to make sure it happens once and only once really makes sense here.

The scan is gated by two checks now:

kernel/sched/core.c void init_sched_mm_cid(struct task_struct *t) · line 10642

Quoted 2 lines

kernel/sched/core.c +2 -0

+	if (t->mm && rtime > RSEQ_UNPREEMPTED_THRESHOLD) {
+		if (mm_cid_needs_scan(t->mm))

And likewise for the periodic check for preemption:

Quoted 1 line

kernel/sched/core.c +1 -0

+	if (t->mm && rtime > RSEQ_UNPREEMPTED_THRESHOLD) {

[...]

Quoted 4 lines

kernel/sched/core.c +3 -0

+		else if (time_after(jiffies, t->last_rseq_preempt
+
+				     

msecs_to_jiffies(MM_CID_SCAN_DELAY))) {

Those second levels of time checks would prevent adding significant overhead on every tick after the threshold is reached.

Quoted 13 lines

B is occurring after the work updates the last scan time, so we are in a
condition where the runtime is above threshold but the (next) scan time
did not expire yet.
I tried to account for multiple threads updating the mm_cid (not necessarily the long running one, or in case more are long running), for
this I'm tracking the last time we updated the mm_cid, if that occurred
before the last mm_cid scan, we need to update (and preempt).

Quoted 1 line

Does this make sense to you?

It makes sense. Note that it adds overhead to rseq_preempt() (a store to t->last_rseq_preempt), which is a fast path. I don't know if we should care.

Also part of task_tick_mm_cid could be moved to a helper, e.g.:

static
void task_reset_mm_cid(struct rq *rq, struct task_struct *t) {
         int old_cid = t->mm_cid;

         if (!t->mm_cid_active)
                 return;
         mm_cid_snapshot_time(rq, t->mm); mm_cid_put_lazy(t);
         t->last_mm_cid = t->mm_cid = mm_cid_get(rq, t, t->mm); if (old_cid == t->mm_cid)
                 return;
         rseq_preempt(t);
}

This patchset moves the task_mm_cid_work to a preemptible and migratable
context. This reduces the impact of this work to the scheduling latency
of real time tasks.
The change makes the recurrence of the task a bit more predictable.

The behaviour causing latency was introduced in commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") which introduced a task work tied to the scheduler tick.
That approach presents two possible issues:
* the task work runs before returning to user and causes, in fact, a scheduling latency (with order of magnitude significant in PREEMPT_RT)
* periodic tasks with short runtime are less likely to run during the tick, hence they might not run the task work at all

Patch 1 add support for prev_sum_exec_runtime to the RT, deadline and sched_ext classes as it is supported by fair, this is required to avoid
calling rseq_preempt on tick if the runtime is below a threshold.

Patch 2 contains the main changes, removing the task_work on the scheduler tick and using a work_struct scheduled more reliably during __rseq_handle_notify_resume.

Patch 3 adds a selftest to validate the functionality of the task_mm_cid_work (i.e. to compact the mm_cids).

Changes since V11:
* Remove variable to make mm_cid_needs_scan more compact
* All patches reviewed

Changes since V10:
* Fix compilation errors with RSEQ and/or MM_CID disabled

Changes since V9:
* Simplify and move checks from task_queue_mm_cid to its call site

Changes since V8 [1]:
* Add support for prev_sum_exec_runtime to RT, deadline and sched_ext
* Avoid rseq_preempt on ticks unless executing for more than 100ms
* Queue the work on the unbound workqueue

Changes since V7:
* Schedule mm_cid compaction and update at every tick too
* mmgrab before scheduling the work

Changes since V6 [2]:
* Switch to a simple work_struct instead of a delayed work
* Schedule the work_struct in __rseq_handle_notify_resume
* Asynchronously disable the work but make sure mm is there while we run
* Remove first patch as merged independently
* Fix commit tag for test

Changes since V5:
* Punctuation

Changes since V4 [3]:
* Fixes on the selftest
    * Polished memory allocation and cleanup
    * Handle the test failure in main

Changes since V3 [4]:
* Fixes on the selftest
    * Minor style issues in comments and indentation
    * Use of perror where possible
    * Add a barrier to align threads execution
    * Improve test failure and error handling

Changes since V2 [5]:
* Change the order of the patches
* Merge patches changing the main delayed_work logic
* Improved self-test to spawn 1 less thread and use the main one instead

Changes since V1 [6]:
* Re-arm the delayed_work at each invocation
* Cancel the work synchronously at mmdrop
* Remove next scan fields and completely rely on the delayed_work
* Shrink mm_cid allocation with nr thread/affinity (Mathieu Desnoyers)
* Add self test

[1] -
https://lore.kernel.org/lkml/[email protected]
[2] -
https://lore.kernel.org/lkml/[email protected]
[3] -
https://lore.kernel.org/lkml/[email protected]
[4] -
https://lore.kernel.org/lkml/[email protected]
[5] -
https://lore.kernel.org/lkml/[email protected]
[6] -
https://lore.kernel.org/lkml/[email protected]

To: Mathieu Desnoyers <[email protected]>
To: Peter Zijlstra <[email protected]>
To: Ingo Molnar <[email protected]>
To: Paul E. McKenney <[email protected]>
To: Shuah Khan <[email protected]>

Gabriele Monaco (3):
  sched: Add prev_sum_exec_runtime support for RT, DL and SCX classes
  sched: Move task_mm_cid_work to mm work_struct selftests/rseq: Add test for mm_cid compaction

 include/linux/mm_types.h                      |  17 ++ include/linux/rseq.h                          |  13 ++ include/linux/sched.h                         |   7 +- kernel/rseq.c                                 |   2 + kernel/sched/core.c                           |  43 ++-- kernel/sched/deadline.c                       |   1 + kernel/sched/ext.c                            |   1 + kernel/sched/rt.c                             |   1 + kernel/sched/sched.h                          |   2 - tools/testing/selftests/rseq/.gitignore       |   1 + tools/testing/selftests/rseq/Makefile         |   2 +- .../selftests/rseq/mm_cid_compaction_test.c   | 200
++++++++++++++++++

 12 files changed, 258 insertions(+), 32 deletions(-)

 create mode 100644 tools/testing/selftests/rseq/mm_cid_compaction_test.c

base-commit: 80e54e84911a923c40d7bee33a34c1b4be148d7a

Quoted 7 lines · Gabriele Monaco

This patchset moves the task_mm_cid_work to a preemptible and migratable
context. This reduces the impact of this work to the scheduling latency
of real time tasks.
The change makes the recurrence of the task a bit more predictable.

The series was review and, in my opinion, is ready for inclusion. Peter, Ingo, can we merge it?

Thanks,
Gabriele

Quoted 121 lines

The behaviour causing latency was introduced in commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") which introduced a task work tied to the scheduler tick.
That approach presents two possible issues:
* the task work runs before returning to user and causes, in fact, a scheduling latency (with order of magnitude significant in
PREEMPT_RT)
* periodic tasks with short runtime are less likely to run during the tick, hence they might not run the task work at all

Patch 1 add support for prev_sum_exec_runtime to the RT, deadline and sched_ext classes as it is supported by fair, this is required to avoid
calling rseq_preempt on tick if the runtime is below a threshold.

Patch 2 contains the main changes, removing the task_work on the scheduler tick and using a work_struct scheduled more reliably during __rseq_handle_notify_resume.

Patch 3 adds a selftest to validate the functionality of the task_mm_cid_work (i.e. to compact the mm_cids).

Changes since V11:
* Remove variable to make mm_cid_needs_scan more compact
* All patches reviewed

Changes since V10:
* Fix compilation errors with RSEQ and/or MM_CID disabled

Changes since V9:
* Simplify and move checks from task_queue_mm_cid to its call site

Changes since V8 [1]:
* Add support for prev_sum_exec_runtime to RT, deadline and sched_ext
* Avoid rseq_preempt on ticks unless executing for more than 100ms
* Queue the work on the unbound workqueue

Changes since V7:
* Schedule mm_cid compaction and update at every tick too
* mmgrab before scheduling the work

Changes since V6 [2]:
* Switch to a simple work_struct instead of a delayed work
* Schedule the work_struct in __rseq_handle_notify_resume
* Asynchronously disable the work but make sure mm is there while we run
* Remove first patch as merged independently
* Fix commit tag for test

Changes since V5:
* Punctuation

Changes since V4 [3]:
* Fixes on the selftest
    * Polished memory allocation and cleanup
    * Handle the test failure in main

Changes since V3 [4]:
* Fixes on the selftest
    * Minor style issues in comments and indentation
    * Use of perror where possible
    * Add a barrier to align threads execution
    * Improve test failure and error handling

Changes since V2 [5]:
* Change the order of the patches
* Merge patches changing the main delayed_work logic
* Improved self-test to spawn 1 less thread and use the main one instead

Changes since V1 [6]:
* Re-arm the delayed_work at each invocation
* Cancel the work synchronously at mmdrop
* Remove next scan fields and completely rely on the delayed_work
* Shrink mm_cid allocation with nr thread/affinity (Mathieu Desnoyers)
* Add self test

[1] -
https://lore.kernel.org/lkml/[email protected]
[2] -
https://lore.kernel.org/lkml/[email protected]
[3] -
https://lore.kernel.org/lkml/[email protected]
[4] -
https://lore.kernel.org/lkml/[email protected]
[5] -
https://lore.kernel.org/lkml/[email protected]
[6] -
https://lore.kernel.org/lkml/[email protected]

To: Mathieu Desnoyers <[email protected]>
To: Peter Zijlstra <[email protected]>
To: Ingo Molnar <[email protected]>
To: Paul E. McKenney <[email protected]>
To: Shuah Khan <[email protected]>

Gabriele Monaco (3):
  sched: Add prev_sum_exec_runtime support for RT, DL and SCX classes
  sched: Move task_mm_cid_work to mm work_struct selftests/rseq: Add test for mm_cid compaction

  include/linux/mm_types.h                      |  17 ++
  include/linux/rseq.h                          |  13 ++
  include/linux/sched.h                         |   7 +-
  kernel/rseq.c                                 |   2 +
  kernel/sched/core.c                           |  43 ++--
  kernel/sched/deadline.c                       |   1 +
  kernel/sched/ext.c                            |   1 +
  kernel/sched/rt.c                             |   1 +
  kernel/sched/sched.h                          |   2 -
  tools/testing/selftests/rseq/.gitignore       |   1 +
  tools/testing/selftests/rseq/Makefile         |   2 +-
  .../selftests/rseq/mm_cid_compaction_test.c   | 200
++++++++++++++++++
  12 files changed, 258 insertions(+), 32 deletions(-)

 create mode 100644
tools/testing/selftests/rseq/mm_cid_compaction_test.c

base-commit: 80e54e84911a923c40d7bee33a34c1b4be148d7a

Quoted 10 lines · Gabriele Monaco

Quoted 8 lines · Gabriele Monaco

This patchset moves the task_mm_cid_work to a preemptible and migratable
context. This reduces the impact of this work to the scheduling latency
of real time tasks.
The change makes the recurrence of the task a bit more predictable.

Quoted 2 lines

The series was review and, in my opinion, is ready for inclusion. Peter, Ingo, can we merge it?

I agree. I've reviewed the entire series a few weeks ago and it looks good to me.