Re: racy acccess in kern_runq.c

[Andrew Doran <ad%netbsd.org@localhost>]

Hi,

On Fri, Dec 06, 2019 at 03:52:23PM +0900, Kengo NAKAHARA wrote:

> There are some racy accesses in kern_runq.c detected by KCSAN.  Those
> racy access messages is so frequency that they cover other messages,
> so I want to fix them.  They can be fixed by the following patch.

Please don't commit this.  These accesses are racy by design.  There is no
safety issue and we do not want to disturb the activity of other CPUs in
this code path by locking them.  We also don't want to use atomics either. 
This code path is extremely hot using atomics would impose a severe
performance penalty on the system under certain workloads.

Also if you change this to use strong ordering, you're quite likely to
change the selection behaviour of LWPs.  This is something delicate that
exhibits reasonable scheduling behaviour in large part through randomness
i.e by accident, so serialising it it's likely to have strong effects on how
LWPs are distributed.

Lastly I have a number of experimental changes to this code which I'll be
committing in the near future allowing people to change the LWP selection
policy to see how if we can improve performance under different workloads. 
They will also likely show up in KCSAN as racy/dangerous accesses.

My suggestion is to find a way to teach KCSAN that we know something is
racy, we like it being racy, and that it's not a problem, so that it no
longer shows up in the KCSAN output.

Thank you,
Andrew