On Tue, May 14, 2019 at 10:54 PM Greg Troxel <g...@lexort.com> wrote: > > Ryota Ozaki <ozak...@netbsd.org> writes: > > > On Tue, May 14, 2019 at 2:31 AM Jason Thorpe <thor...@me.com> wrote: > >> > >> > >> > >> > On May 13, 2019, at 7:17 AM, Greg Troxel <g...@lexort.com> wrote: > >> > > >> > 2) Your option 2 seems to involve two things at once: > >> > > >> > - migration to lwp_specificadata > >> > - using DEBUG instead of DIAGNOSTIC to control the leak check feature > >> > > >> > I do not understand why changing the nature of the implementation is > >> > linked to how it is enabled. > >> > >> I think Ozaki-san saying that the 3% performance hit only happens > >> when lwp_specificdata is used, and hence that it would need to be > >> wrapped in DEBUG rather than DIAGNOSTIC. > > Now this is all making sense. > > >> The original negligible-impact implementation did NOT use > >> lwp_specificdata, and thus was fine for DIAGNOSTIC. I believe > >> Ozaki-san's preference is to use *this* implementation so that it > >> can be exposed to a wider audience. The lwp_specificdata approach > >> was only explored after someone else suggested a preference for it. > >> > >> At least, that's my understanding of the situation. > > > > Yes, your understanding is correct. Thank you for the clarification. > > So having a check under DIAGNOSTIC that you more or less can't measure > sounds just fine to me. I only meant to object to a 3% slowdown under > DIAGNOSTIC. > > And, if someone is inclined, having better checks with meaurable > slowdown under DEBUG sounds ok too, but my revised understanding is > unclear on whether that's helpful. (But I am only trying to keep > performance under DIAGNOSTIC high; I am unconcerned about DEBUG and > don't need to understand.)
I've proposed another implementation a few days ago (*). That provides useful information for debugging in exchange for expensive overhead. It is enabled by PSREF_DEBUG. (*) https://mail-index.netbsd.org/tech-kern/2019/05/10/msg025049.html ozaki-r
