Re: Debugging function of localcount

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Thu, Jul 27, 2017 at 1:49 AM, Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>> Date: Wed, 26 Jul 2017 18:41:36 +0900
>> From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
>>
>> Oops. I thought we could use percpu_foreach in softint, but
>> I was wrong. So localcount_debug_refcnt can be used only
>> in thread contexts. And the above assertion shouldn't be
>> there. The proposal isn't so much worthwhile ;-<
>
> You also can't access one CPU's count from another CPU -- there's no
> memory ordering, so you can easily get wildly inconsistent answers.
>
> Maybe if you did a cross-call to count it up, that would work, but it
> sounds like for the cases you had in mind, you can't do a cross-call,
> and I'm not sure the view is guaranteed to be stable enough: maybe one
> thread decrements the count on CPU 0, then you count 'em up, then the
> thread migrates to CPU 1 and increments the count there.  (It is not a
> theorem that something like this might violate your assertion, just a
> conjecture!)

Yes, so I expected the uses in very limited environments like ATF tests
using rump kernels.

Anyway I've brought another (stupid) approach that uses an atomic
counter:
  http://www.netbsd.org/~ozaki-r/localcount_debug_atomic.diff

It counts up a counter with atomic instructions along with localcount
if LOCKDEBUG enabled. Of course it blows the merit of localcount but
I can provide an accurate view of the counter.

Do you think that it works and is useful?

  ozaki-r