From: Peter Zijlstra <peterz@infradead.org>
To: Peter Oskolkov <posk@google.com>
Cc: mingo@redhat.com, tglx@linutronix.de, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
bristot@redhat.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-api@vger.kernel.org, x86@kernel.org,
pjt@google.com, avagin@google.com, jannh@google.com,
tdelisle@uwaterloo.ca, posk@posk.io
Subject: Re: [RFC PATCH v2 4/5] sched: UMCG: add a blocked worker list
Date: Thu, 27 Jan 2022 16:37:49 +0100 [thread overview]
Message-ID: <20220127153749.GP20638@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20220113233940.3608440-5-posk@google.com>
On Thu, Jan 13, 2022 at 03:39:39PM -0800, Peter Oskolkov wrote:
> This change introduces the following benefits:
> - block detection how behaves similarly to wake detection;
> without this patch worker wakeups added wakees to the list
> and woke the server, while worker blocks only woke the server
> without adding blocked workers to a list, forcing servers
> to explicitly check worker's state;
> - if the blocked worker woke sufficiently quickly, the server
> woken on the block event would observe its worker now as
> RUNNABLE, so the block event had to be inferred rather than
> explicitly signalled by the worker being added to the blocked
> worker list;
This I think is missing the point, there is no race if the server checks
curr->state == RUNNING.
> - it is now possible for a single server to control several
> RUNNING workers, which makes writing userspace schedulers
> simpler for smaller processes that do not need to scale beyond
> one "server";
How about something like so on top?
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1298,6 +1298,7 @@ struct task_struct {
#ifdef CONFIG_UMCG
/* setup by sys_umcg_ctrl() */
+ u32 umcg_flags;
clockid_t umcg_clock;
struct umcg_task __user *umcg_task;
--- a/include/uapi/linux/umcg.h
+++ b/include/uapi/linux/umcg.h
@@ -119,6 +119,8 @@ struct umcg_task {
*
* Readable/writable by both the kernel and the userspace: the
* kernel adds items to the list, userspace removes them.
+ *
+ * Only used with UMCG_CTL_MULTI.
*/
__u64 blocked_workers_ptr; /* r/w */
@@ -147,11 +149,13 @@ enum umcg_wait_flag {
* @UMCG_CTL_REGISTER: register the current task as a UMCG task
* @UMCG_CTL_UNREGISTER: unregister the current task as a UMCG task
* @UMCG_CTL_WORKER: register the current task as a UMCG worker
+ * @UMCG_CTL_MULTI: allow 1:n worker relations, enables blocked_workers_ptr
*/
enum umcg_ctl_flag {
UMCG_CTL_REGISTER = 0x00001,
UMCG_CTL_UNREGISTER = 0x00002,
UMCG_CTL_WORKER = 0x10000,
+ UMCG_CTL_MULTI = 0x20000,
};
#endif /* _UAPI_LINUX_UMCG_H */
--- a/kernel/sched/umcg.c
+++ b/kernel/sched/umcg.c
@@ -335,7 +335,7 @@ static inline int umcg_enqueue_runnable(
}
/*
- * Enqueue @tsk on it's server's blocked list
+ * Enqueue @tsk on it's server's blocked list OR ensure @tsk == server::next_tid
*
* Must be called in umcg_pin_pages() context, relies on tsk->umcg_server.
*
@@ -346,10 +346,34 @@ static inline int umcg_enqueue_runnable(
* Returns:
* 0: success
* -EFAULT
+ * -ESRCH server::next_tid is not a valid UMCG task
+ * -EINVAL server::next_tid doesn't match @tsk
*/
static inline int umcg_enqueue_blocked(struct task_struct *tsk)
{
- return umcg_enqueue(tsk, true /* blocked */);
+ struct task_struct *next;
+ u32 next_tid;
+ int ret;
+
+ if (tsk->umcg_server->umcg_flags & UMCG_CTL_MULTI)
+ return umcg_enqueue(tsk, true /* blocked */);
+
+ /*
+ * When !MULTI, ensure this worker is the current worker,
+ * ensuring the 1:1 relation.
+ */
+ if (get_user(next_tid, &tsk->umcg_server_task->next_tid))
+ return -EFAULT;
+
+ next = umcg_get_task(next_tid);
+ if (!next)
+ return -ESRCH;
+
+ ret = (next == tsk) ? 0 : -EINVAL;
+
+ put_task_struct(next);
+
+ return ret;
}
/* pre-schedule() */
@@ -911,6 +934,8 @@ static int umcg_register(struct umcg_tas
return -EINVAL;
}
+ current->umcg_flags = flags;
+
if (current->umcg_task || !self)
return -EINVAL;
@@ -1061,7 +1086,7 @@ SYSCALL_DEFINE3(umcg_ctl, u32, flags, st
flags &= ~UMCG_CTL_CMD;
- if (flags & ~(UMCG_CTL_WORKER))
+ if (flags & ~(UMCG_CTL_WORKER|UMCG_CTL_MULTI))
return -EINVAL;
switch (cmd) {
next prev parent reply other threads:[~2022-01-27 15:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 23:39 [RFC PATCH v2 0/5] User Managed Concurrency Groups Peter Oskolkov
2022-01-13 23:39 ` [RFC PATCH v2 1/5] sched/umcg: add WF_CURRENT_CPU and externise ttwu Peter Oskolkov
2022-01-13 23:39 ` [RFC PATCH v2 2/5] x86/uaccess: Implement unsafe_try_cmpxchg_user() Peter Oskolkov
2022-01-13 23:39 ` [RFC PATCH v2 3/5] sched: User Mode Concurency Groups Peter Oskolkov
2022-01-13 23:39 ` [RFC PATCH v2 4/5] sched: UMCG: add a blocked worker list Peter Oskolkov
2022-01-17 9:19 ` Peter Zijlstra
2022-01-18 17:16 ` Peter Oskolkov
2022-01-27 15:37 ` Peter Zijlstra [this message]
2022-01-27 17:20 ` Peter Oskolkov
2022-01-13 23:39 ` [RFC PATCH v2 5/5] sched: UMCG: allow to sys_umcg_kick UMCG servers Peter Oskolkov
2022-01-27 16:35 ` Peter Zijlstra
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=20220127153749.GP20638@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=avagin@google.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jannh@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=pjt@google.com \
--cc=posk@google.com \
--cc=posk@posk.io \
--cc=rostedt@goodmis.org \
--cc=tdelisle@uwaterloo.ca \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox