From: Thierry Delisle <tdelisle@uwaterloo.ca>
To: Peter Oskolkov <posk@posk.io>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
<linux-api@vger.kernel.org>, 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: Tue, 12 Oct 2021 12:25:31 -0400 [thread overview]
Message-ID: <e162fdea-5323-89d2-49d0-3fe56ba2ec3a@uwaterloo.ca> (raw)
In-Reply-To: <CAFTs51W6ZHrGaoXEbXNCkVKLxe7_S2raYcXMBzypC7VUDMrU-w@mail.gmail.com>
> Hi Thierry,
>
> sorry for the delayed reply - I'm finally going through the
> documentation patches in preparation for the upcoming next version
> patchset mail-out.
No problem.
> The documentation here outlines what sys_umcg_wait does, and it does
> put the current task to sleep without context switching if next_tid is
> zero. The question of whether this behavior is or is not appropriate
> for a worker wishing to yield/park itself is at a "policy" level, if
> you wish, and this "policy" level is described in "state transitions"
> section later in the document. sys_umcg_wait() does not enforce this
> "policy" directly, in order to make it simpler and easier to describe
> and reason about.
Just to be clear, sys_umcg_wait supports an operation that, when called
from
a worker, puts the worker to sleep without triggering block detection
or context-switching back 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.
>
> I'm not a fan of arguing about how to name things. If the maintainers
> ask me to rename wait/wake to park/unpark, I'll do that.
I understand the sentiment, and I'm perfectly happy with the use of
wait/wake.
I was exclusively referring to this one use of "yield" in the
documentation.
next prev parent reply other threads:[~2021-10-12 16:25 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
2021-10-11 22:45 ` Peter Oskolkov
2021-10-12 16:25 ` Thierry Delisle [this message]
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=e162fdea-5323-89d2-49d0-3fe56ba2ec3a@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).