From nobody Fri Jun 18 13:35:44 2021 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9FBDE7E8353 for ; Fri, 18 Jun 2021 13:35:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G60LP40Y8z4Tkw for ; Fri, 18 Jun 2021 13:35:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72e.google.com with SMTP id f70so10893964qke.13 for ; Fri, 18 Jun 2021 06:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s8yyBCsaUp8R0lcdVPnKK3oRtq+82l8vomPz5cOAyQY=; b=wy5TfojC4lzGFnEZjotq0o5W9Ga0ZakkmBBBEqJbnL0IaIy+GFdiVdCtp3ErqOOyrU ZD7Zbeg1Mk7qV0hTTiyo2zGs/OGMXEjxrWKV4enVuXxKjnG/pxW554Ezmm4ASBvJlVuw BgQb0HriaMYzYvG9fERIUDTIJqHuCpJxR/dhHEUYgOebUxgiSwuHOWjqpon2Xeqhq3D8 aYy2WzRgz4O1Q854ij16jhzo7+IUVxNOD3NVF8AaF+QmeN3KVEPP6nzg711daR0WENs1 3hO+2Osb7uPnxpwEX0SFCJOuorJNv1/tQDSFxGubqj7Ox/+nLZ9kpNKsBPtEfxbBcGDQ GdNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s8yyBCsaUp8R0lcdVPnKK3oRtq+82l8vomPz5cOAyQY=; b=rj2L0eHQjYD05c0O8CnUgdaTdlfhxLTU/QQ5Fa2bBXtUgbu2fMThEpEDnF1LSqiQec IMuP3wga/t6p1FRPjO4m2VXIQXchTQqTORpzhnhVboeETMjMYxKtG4xH7Ir1Njynpop5 YToekNE/LAK5LnYie8WCTTHXML7Sk21J5SBxNkzgh3f9eJOE/orpkWzcD3s8TZqOjTp+ qWbH6bO3pJ/GqmtuLe/BCmYyotGFg5a1ZWAXczIAS6gp40nXIvHOrKwZCZ5dRhfLRgZ5 Xivdy8H2pbQN2sfJutdoaFZk02HEFfkDu7dAeP/QT42GrN91AJ3vWtaV4dUWFKi/Zvbh POfA== X-Gm-Message-State: AOAM531BEmgbQMAGzLtOHPTSFeGXT7X/+4bWwHTO2kLcXgnMSkQgSw+B Z3pLN3GRoAG6RAmEYKIr9y7AoCsmZ2mR4oj77+o94DVaFI3xzg== X-Google-Smtp-Source: ABdhPJz0VIVDJcBs9iSWq07crxVISo/hQxq9aGwBGQXi224cnpO+aAOI2HV3tZ6+Jfx/JeN+nqMZAgEDF4yFPEK3RPM= X-Received: by 2002:a37:a20f:: with SMTP id l15mr9293519qke.44.1624023355266; Fri, 18 Jun 2021 06:35:55 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202106180736.15I7aYmk068064@critter.freebsd.dk> In-Reply-To: <202106180736.15I7aYmk068064@critter.freebsd.dk> From: Warner Losh Date: Fri, 18 Jun 2021 07:35:44 -0600 Message-ID: Subject: Re: It's time to kill statistical profiling To: Poul-Henning Kamp Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000032b14b05c50a673b" X-Rspamd-Queue-Id: 4G60LP40Y8z4Tkw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000032b14b05c50a673b Content-Type: text/plain; charset="UTF-8" On Fri, Jun 18, 2021 at 1:37 AM Poul-Henning Kamp 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--