Date: Fri, 18 Jun 2021 07:35:44 -0600 From: Warner Losh <imp@bsdimp.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: It's time to kill statistical profiling Message-ID: <CANCZdfr5po5gc2JjjJTd7sWoL9z0sHWQK9myhy774rz%2BH9MYJA@mail.gmail.com> In-Reply-To: <202106180736.15I7aYmk068064@critter.freebsd.dk> References: <202106180736.15I7aYmk068064@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000032b14b05c50a673b Content-Type: text/plain; charset="UTF-8" On Fri, Jun 18, 2021 at 1:37 AM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > Warners work to document the kernel timers in D30802 brought stathz up > again. > > To give a representative result, statistical profiling needs to > sample no less than approx 0.1% of instructions. > > On a VAX that meant running the statistical profiling at O(1kHz). > > On my 4 CPU, two thread, 2GHz laptop that means statistical profiling > needs to run at O(10 MHz), which is barely doable. > > But it is worse: > > The samples must be unbiased with respect to the system activity, > which was already a problem on the VAX and which is totally impossible > on modern hardware, with message based interrupts, deep pipelines > and telegraphic distance memory[1]. > > Therefore statistical profiling is worse than useless: it is downright > misleading, which is why modern CPUs have hardware performance counters. > > Instead of documenting stathz, I suggest we retire statistical > profiling and convert the profiled libraries to code-coverage > profiling (-fprofile-arcs and -ftest-coverage) > > Poul-Henning > > [1] One could *possibly* approch unbiased samples, by locking the > stathz code path in L1 cache and disable L1 updates, but then > the results would be from an entirely different system. > I've documented them as obsolete in favor of hwpmc (though I know that's not quite the whole story). I'll remove that when we remove the feature, since it also documents the clockinfo sysctl a bit. stathz and profhz drive the setitimer ITIMER_PROF functionality. While this was in POSIX.1-2001, it was marked deprecated in POSIX.1-2008. There's sysctls that return these values to userland as well, but those could return bogus values. Our current docs for this are vague enough to give some cover :) Deleting the code from the kernel is the easy bit, I guess. I generally support this notion, but don't have the time to hunt down all the stuff in base and ports that uses these and make appropriate changes (up to and including git rm). Warner --00000000000032b14b05c50a673b--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr5po5gc2JjjJTd7sWoL9z0sHWQK9myhy774rz%2BH9MYJA>