From: Thierry Delisle <tdelisle@uwaterloo.ca>
To: Peter Oskolkov <posk@posk.io>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
<linux-kernel@vger.kernel.org>, <linux-api@vger.kernel.org>
Cc: Paul Turner <pjt@google.com>, Ben Segall <bsegall@google.com>,
Peter Oskolkov <posk@google.com>,
Andrei Vagin <avagin@google.com>, Jann Horn <jannh@google.com>
Subject: Re: [PATCH 5/5 v0.6] sched/umcg: add Documentation/userspace-api/umcg.txt
Date: Wed, 22 Sep 2021 14:39:04 -0400 [thread overview]
Message-ID: <12eb2300-4a78-9e93-30a3-8e2ddba4693f@uwaterloo.ca> (raw)
In-Reply-To: <20210917180323.278250-6-posk@google.com>
On 2021-09-17 2:03 p.m., Peter Oskolkov wrote:
> [...]
> +SYS_UMCG_WAIT()
> +
> +int sys_umcg_wait(uint32_t flags, uint64_t abs_timeout) operates on
> +registered UMCG servers and workers: struct umcg_task *self provided to
> +sys_umcg_ctl() when registering the current task is consulted in
addition
> +to flags and abs_timeout parameters.
> +
> +The function can be used to perform one of the three operations:
> +
> +* wait: if self->next_tid is zero, sys_umcg_wait() puts the current
> + server or worker to sleep;
I believe this description is misleading but I might be wrong.
From the example
* worker to server context switch (worker "yields"):
S:IDLE+W:RUNNING => +S:RUNNING+W:IDLE
It seems to me that when a worker goes from running to idle, it should
*not* set the next_tid to 0, it should preserve the next_tid as-is,
which is expected to point to its current server. This is consistent
with my understanding of the umcg_wait implementation. This operation
is effectively a direct context-switch to the server.
With that said, I'm a little confused by the usage of "yields" in that
example. I would expect workers yielding to behave like kernel threads
calling sched_yield(), i.e., context switch to the server but also be
immediately added to the idle_workers_ptr.
From my understanding of the umcg_wait call, "worker to server context
switch" does not have analogous behaviour to sched_yield. Am I correct?
If so, I suggest using "park" instead of "yield" in the description
of that example. I believe the naming of wait/wake as park/unpark is
consistent with Java[1] and Rust[2], but I don't know if that naming
is used in contexts closer to the linux kernel.
[1]
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/LockSupport.html
[2] https://doc.rust-lang.org/std/thread/fn.park.html
next prev parent reply other threads:[~2021-09-22 18:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 18:03 [PATCH 0/5 v0.6] sched/umcg: RFC UMCG patchset Peter Oskolkov
2021-09-17 18:03 ` [PATCH 1/5 v0.6] sched/umcg: add WF_CURRENT_CPU and externise ttwu Peter Oskolkov
2021-09-17 18:03 ` [PATCH 2/5 v0.6] sched/umcg: RFC: add userspace atomic helpers Peter Oskolkov
2021-09-19 18:25 ` Tao Zhou
2021-09-28 21:58 ` Thomas Gleixner
2021-09-28 23:07 ` Peter Oskolkov
2021-09-17 18:03 ` [PATCH 3/5 v0.6] sched/umcg: RFC: implement UMCG syscalls Peter Oskolkov
2021-09-19 18:25 ` Tao Zhou
2021-09-28 9:21 ` Thomas Gleixner
2021-09-28 17:26 ` Peter Oskolkov
2021-09-28 20:00 ` Thomas Gleixner
2021-09-17 18:03 ` [PATCH 4/5 v0.6] sched/umcg: add Documentation/userspace-api/umcg.rst Peter Oskolkov
2021-09-17 18:03 ` [PATCH 5/5 v0.6] sched/umcg: add Documentation/userspace-api/umcg.txt Peter Oskolkov
2021-09-22 18:39 ` Thierry Delisle [this message]
2021-10-11 22:45 ` Peter Oskolkov
2021-10-12 16:25 ` Thierry Delisle
2021-10-12 16:58 ` Peter Oskolkov
2021-10-12 18:46 ` Thierry Delisle
2021-10-12 21:44 ` Peter Oskolkov
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=12eb2300-4a78-9e93-30a3-8e2ddba4693f@uwaterloo.ca \
--to=tdelisle@uwaterloo.ca \
--cc=avagin@google.com \
--cc=bsegall@google.com \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=posk@google.com \
--cc=posk@posk.io \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).