linux-kernel - Re: [RFC PATCH] perf: New start period for the freq mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240902103838.GF4723@noisy.programming.kicks-ass.net>
Date: Mon, 2 Sep 2024 12:38:38 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: kan.liang@...ux.intel.com, mingo@...hat.com, tglx@...utronix.de,
	acme@...nel.org, mark.rutland@....com,
	alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
	irogers@...gle.com, adrian.hunter@...el.com,
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
	ravi.bangoria@....com, sandipan.das@....com,
	atrajeev@...ux.vnet.ibm.com, luogengkun@...weicloud.com,
	ak@...ux.intel.com
Subject: Re: [RFC PATCH] perf: New start period for the freq mode

On Thu, Aug 29, 2024 at 11:13:42PM -0700, Namhyung Kim wrote:
> Hi Kan,
> 
> On Thu, Aug 29, 2024 at 08:20:36AM -0700, kan.liang@...ux.intel.com wrote:
> > From: Kan Liang <kan.liang@...ux.intel.com>
> > 
> > The freq mode is the current default mode of Linux perf. 1 period is
> > used as a start period. The period is auto-adjusted in each tick or an
> > overflow to meet the frequency target.
> > 
> > The start period 1 is too low and may trigger some issues.
> > - Many HWs do not support period 1 well.
> >   https://lore.kernel.org/lkml/875xs2oh69.ffs@tglx/

So we already have x86_pmu::limit_period and pmu::check_period to deal
with this. Don't they already capture the 1 and increase it where
appropriate?

> > - For an event that occurs frequently, period 1 is too far away from the
> >   real period. Lots of the samples are generated at the beginning.
> >   The distribution of samples may not be even.

Which is why samples include a WEIGHT option IIRC.

> Sounds like a per-pmu callback is fine.  PMUs don't have the callback
> (including SW) can use 1 same as of now.

This, but also, be very careful to not over-estimate, because ramping up
is fast, but having to adjust down can take a while.