lkml.org 
[lkml]   [2021]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 5/5 v0.6] sched/umcg: add Documentation/userspace-api/umcg.txt
From
Date
 > 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.

\
 
 \ /
  Last update: 2021-10-12 18:26    [W:0.228 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site