From: Tejun Heo <tj@kernel.org>
To: David Vernet <void@manifault.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH RESEND sched_ext/for-6.12] sched_ext: Don't use double locking to migrate tasks across CPUs
Date: Tue, 13 Aug 2024 09:09:27 -1000 [thread overview]
Message-ID: <ZruvZ4jVMQ-5hfjk@slm.duckdns.org> (raw)
In-Reply-To: <ZrQAB_d1WSqgYQmB@slm.duckdns.org>
On Wed, Aug 07, 2024 at 01:15:19PM -1000, Tejun Heo wrote:
> consume_remote_task() and dispatch_to_local_dsq() use
> move_task_to_local_dsq() to migrate the task to the target CPU. Currently,
> move_task_to_local_dsq() expects the caller to lock both the source and
> destination rq's. While this may save a few lock operations while the rq's
> are not contended, under contention, the double locking can exacerbate the
> situation significantly (refer to the linked message below).
>
> Update the migration path so that double locking is not used.
> move_task_to_local_dsq() now expects the caller to be locking the source rq,
> drops it and then acquires the destination rq lock. Code is simpler this way
> and, on a 2-way NUMA machine w/ Xeon Gold 6138, 'hackbench 100 thread 5000`
> shows ~3% improvement with scx_simple.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Link: http://lkml.kernel.org/r/20240806082716.GP37996@noisy.programming.kicks-ass.net
Applied to sched_ext/for-6.12.
Thanks.
--
tejun
prev parent reply other threads:[~2024-08-13 19:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 23:14 [sched_ext/for-6.12] sched_ext: Don't use double locking to migrate tasks across CPUs Tejun Heo
2024-08-07 23:15 ` [PATCH RESEND sched_ext/for-6.12] " Tejun Heo
2024-08-08 18:19 ` David Vernet
2024-08-08 18:24 ` Tejun Heo
2024-08-08 18:25 ` David Vernet
2024-08-13 19:09 ` Tejun Heo [this message]
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=ZruvZ4jVMQ-5hfjk@slm.duckdns.org \
--to=tj@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=void@manifault.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox