> On Dec 16, 2020, at 18:40, Martin Pieuchot <m...@openbsd.org> wrote: > > On 16/12/20(Wed) 23:23, Claudio Jeker wrote: >>> On Wed, Dec 16, 2020 at 04:50:42PM -0300, Martin Pieuchot wrote: >>> [...] >>> Why did we choose to use a variable over NULL? Any technical reason? >> >> The sleep subsytem requires a non-NULL value for ident. Changing this >> seems not trivial. > > I'd say this is an implementation detail, nothing prevent us to use a > "private" ident value if NULL is passed to tsleep(9) :) > >>> I'm wondering it the locality of the variable might not matter in a >>> distant future. Did you dig a bit deeper about the FreeBSD solution? >>> Why did they choose a per-CPU value? >> >> Currently all sleep channels are hashed into IIRC 128 buckets. If all >> timeouts use the same sleep channel then this queue may get overcrowded. >> I guess only instrumentation and measurements will tell us how bad the >> sleep queue is hashed. > > So using a global as sleep channel is not optimum? Would it be better > to use an address on the stack? If so we could make sleep_setup() accept > NULL and use 'sls' for example.
Yes, I think that scheme would dodge any issues with overuse of a single global channel. Plus, "tsleep_nsec(NULL, ...)" looks about right. Passing NULL as the wakeup channel to say "I don't want any wakeup(9) broadcasts" is intuitive. More intuitive than handrolling a private channel on the stack or (as clever as I think it is) "deadchan".
