From: Peter Zijlstra <peterz@infradead.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Song Liu <songliubraving@fb.com>,
Josh Poimboeuf <jpoimboe@kernel.org>, Rik van Riel <riel@fb.com>,
"song@kernel.org" <song@kernel.org>,
"joe.lawrence@redhat.com" <joe.lawrence@redhat.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"live-patching@vger.kernel.org" <live-patching@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jpoimboe@redhat.com" <jpoimboe@redhat.com>
Subject: Re: [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched
Date: Fri, 13 May 2022 15:34:08 +0200 [thread overview]
Message-ID: <20220513133408.GI76023@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <Yn5QHpc9YlAbP1li@alley>
On Fri, May 13, 2022 at 02:33:34PM +0200, Petr Mladek wrote:
> My concern is that klp_try_complete_transition() checks all processes
> under read_lock(&tasklist_lock). It might create some contention
> on this lock. I am not sure if this lock is fair. It might slow down
> block writers (creating/deleting tasks).
rwlock_t is sorta fair. Is it fair for process contect usage, but
in-interrupt use will have a reader bias.
That said; contention on tasklist_lock is a real scalability concern.
Can't you use RCU here? With RCU traversal of the tasklist you can miss
new entry (which should already run the new code) or miss exits (which
will stop running code).
next prev parent reply other threads:[~2022-05-13 13:39 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 17:46 [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched Song Liu
2022-05-07 18:26 ` Rik van Riel
2022-05-07 19:04 ` Song Liu
2022-05-07 19:18 ` Rik van Riel
2022-05-08 20:41 ` Peter Zijlstra
2022-05-09 1:07 ` Rik van Riel
2022-05-09 7:04 ` Peter Zijlstra
2022-05-09 8:06 ` Song Liu
2022-05-09 9:38 ` Peter Zijlstra
2022-05-09 14:13 ` Rik van Riel
2022-05-09 15:22 ` Petr Mladek
2022-05-09 15:07 ` Petr Mladek
2022-05-09 16:22 ` Song Liu
2022-05-10 7:56 ` Petr Mladek
2022-05-10 13:33 ` Rik van Riel
2022-05-10 15:44 ` Petr Mladek
2022-05-10 16:07 ` Rik van Riel
2022-05-10 16:52 ` Josh Poimboeuf
2022-05-10 18:07 ` Rik van Riel
2022-05-10 18:42 ` Josh Poimboeuf
2022-05-10 19:45 ` Song Liu
2022-05-10 23:04 ` Josh Poimboeuf
2022-05-10 23:57 ` Song Liu
2022-05-11 0:33 ` Josh Poimboeuf
2022-05-11 9:24 ` Petr Mladek
2022-05-11 16:33 ` Song Liu
2022-05-12 4:07 ` Josh Poimboeuf
2022-05-13 12:33 ` Petr Mladek
2022-05-13 13:34 ` Peter Zijlstra [this message]
2022-05-11 0:35 ` Rik van Riel
2022-05-11 0:37 ` Josh Poimboeuf
2022-05-11 0:46 ` Rik van Riel
2022-05-11 1:12 ` Josh Poimboeuf
2022-05-11 18:09 ` Rik van Riel
2022-05-12 3:59 ` Josh Poimboeuf
2022-05-09 15:52 ` [RFC] sched,livepatch: call stop_one_cpu in klp_check_and_switch_task Rik van Riel
2022-05-09 16:28 ` Song Liu
2022-05-09 18:00 ` Josh Poimboeuf
2022-05-09 19:10 ` Rik van Riel
2022-05-09 19:17 ` Josh Poimboeuf
2022-05-09 19:49 ` Rik van Riel
2022-05-09 20:09 ` Josh Poimboeuf
2022-05-10 0:32 ` Song Liu
2022-05-10 9:35 ` Peter Zijlstra
2022-05-10 1:48 ` Rik van Riel
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=20220513133408.GI76023@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Kernel-team@fb.com \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pmladek@suse.com \
--cc=riel@fb.com \
--cc=song@kernel.org \
--cc=songliubraving@fb.com \
--cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox