linux-kernel - Re: [PATCH 5/5 v0.6] sched/umcg: add Documentation/userspace-api/umcg.txt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e162fdea-5323-89d2-49d0-3fe56ba2ec3a@uwaterloo.ca>
Date:   Tue, 12 Oct 2021 12:25:31 -0400
From:   Thierry Delisle <tdelisle@...terloo.ca>
To:     Peter Oskolkov <posk@...k.io>
CC:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        <linux-api@...r.kernel.org>, Paul Turner <pjt@...gle.com>,
        Ben Segall <bsegall@...gle.com>,
        Peter Oskolkov <posk@...gle.com>,
        Andrei Vagin <avagin@...gle.com>, Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 5/5 v0.6] sched/umcg: add
 Documentation/userspace-api/umcg.txt

 > 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.