All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Gabriele Monaco <gmonaco@redhat.com>
Cc: Ingo Molnar <mingo@redhat.org>, Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH v11 2/3] sched: Move task_mm_cid_work to mm work_struct
Date: Mon, 10 Mar 2025 11:50:23 -0400	[thread overview]
Message-ID: <31fa089d-1f55-4bc7-9323-389fda4cadfa@efficios.com> (raw)
In-Reply-To: <1c161066bcbc916ae9d97e7d1753ee12511da085.camel@redhat.com>

On 2025-03-10 10:46, Gabriele Monaco wrote:
> On Thu, 2025-02-27 at 16:33 +0100, Gabriele Monaco wrote:
>> Currently, the task_mm_cid_work function is called in a task work
>> triggered by a scheduler tick to frequently compact the mm_cids of
>> each
>> process. This can delay the execution of the corresponding thread for
>> the entire duration of the function, negatively affecting the
>> response
>> in case of real time tasks. In practice, we observe task_mm_cid_work
>> increasing the latency of 30-35us on a 128 cores system, this order
>> of
>> magnitude is meaningful under PREEMPT_RT.
>>
>> Run the task_mm_cid_work in a new work_struct connected to the
>> mm_struct rather than in the task context before returning to
>> userspace.
>>
>> This work_struct is initialised with the mm and disabled before
>> freeing
>> it. The queuing of the work happens while returning to userspace in
>> __rseq_handle_notify_resume, maintaining the checks to avoid running
>> more frequently than MM_CID_SCAN_DELAY.
>> To make sure this happens predictably also on long running tasks, we
>> trigger a call to __rseq_handle_notify_resume also from the scheduler
>> tick if the runtime exceeded a 100ms threshold.
>> [...]
>>
>> Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced by
>> mm_cid")
>> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> 
> Is this patch missing anything?
> 
> I refactored a bit to have it build in configurations without RSEQ
> and/or MM_CID (which was failing v10)

Found a small nit. Please fix and resend with my reviewed-by, and
that version will be ready for inclusion.

Thanks!

Mathieu


> 
> Thanks,
> Gabriele
> 


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

  reply	other threads:[~2025-03-10 15:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27 15:33 [PATCH v11 0/3] sched: Restructure task_mm_cid_work for predictability Gabriele Monaco
2025-02-27 15:33 ` [PATCH v11 1/3] sched: Add prev_sum_exec_runtime support for RT, DL and SCX classes Gabriele Monaco
2025-02-27 15:33 ` [PATCH v11 2/3] sched: Move task_mm_cid_work to mm work_struct Gabriele Monaco
2025-03-10 14:46   ` Gabriele Monaco
2025-03-10 15:50     ` Mathieu Desnoyers [this message]
2025-03-10 15:57       ` Gabriele Monaco
2025-03-10 15:49   ` Mathieu Desnoyers
2025-02-27 15:33 ` [PATCH v11 3/3] selftests/rseq: Add test for mm_cid compaction Gabriele Monaco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=31fa089d-1f55-4bc7-9323-389fda4cadfa@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=akpm@linux-foundation.org \
    --cc=gmonaco@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=mingo@redhat.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.