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