Messages in this thread | | | Subject | Re: [PATCH 5/5 v0.6] sched/umcg: add Documentation/userspace-api/umcg.txt | From | Thierry Delisle <> | Date | Tue, 12 Oct 2021 12:25:31 -0400 |
| |
> 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.
| |