Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Date:   Thu, 5 Dec 2019 09:51:39 -0800
Message-Id: <66B551EF-8CC6-4145-9618-8DC4F4498138@amacapital.net>
Subject: Re: Running an Ivy Bridge cpu at fixed frequency
In-Reply-To: <df5b67c5f51b48c391480358d6af53ca@AcuMS.aculab.com>
References: <df5b67c5f51b48c391480358d6af53ca@AcuMS.aculab.com>
To:     David Laight <David.Laight@aculab.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Dec 5, 2019, at 7:54 AM, David Laight <David.Laight@aculab.com> wrote:
>=20
> =EF=BB=BFFrom: Peter Zijlstra
>> Sent: 05 December 2019 09:46
>> As Andy already wrote, perf is really good for this.
>> Find attached, it probably is less shiny than what Andy handed you, but
>> contains all the bits required to frob something.
>=20
> You are in a maze of incomplete documentation all disjoint.

I don=E2=80=99t see any documentation.  Maybe you shouldn=E2=80=99t have tur=
ned your flashlight on.

>=20
> The x86 instruction set doc (eg 325462.pdf) defines the rdpmc instruction,=
 tells you
> how many counters each cpu type has, but doesn't even contain a reference
> to how they are incremented.
> I guess there are some processor-specific MSR for that.
>=20
> perf_event_open(2) tells you a few things, but doesn't actually what anyth=
ing is.
> It contains all but the last 'if' clause of this function, without really s=
aying
> what any of it does - or why you might do it this way.
>=20
> static inline u64 mmap_read_self(void *addr)
> {
>       struct perf_event_mmap_page *pc =3D addr;
>       u32 seq, idx, time_mult =3D 0, time_shift =3D 0, width =3D 0;
>       u64 count, cyc =3D 0, time_offset =3D 0, enabled, running, delta;
>       s64 pmc =3D 0;
>=20
>       do {
>               seq =3D pc->lock;
>               barrier();
>=20
>               enabled =3D pc->time_enabled;
>               running =3D pc->time_running;
>=20
>               if (pc->cap_user_time && enabled !=3D running) {
>                       cyc =3D rdtsc();
>                       time_mult =3D pc->time_mult;
>                       time_shift =3D pc->time_shift;
>                       time_offset =3D pc->time_offset;
>               }
>=20
>               idx =3D pc->index;
>               count =3D pc->offset;
>               if (pc->cap_user_rdpmc && idx) {
>                       width =3D pc->pmc_width;
>                       pmc =3D rdpmc(idx - 1);
>               }
>=20
>               barrier();
>       } while (pc->lock !=3D seq);
>=20
>       if (idx) {
>               pmc <<=3D 64 - width;
>               pmc >>=3D 64 - width; /* shift right signed */
>               count +=3D pmc;
>       }
>=20
>       if (enabled !=3D running) {
>               u64 quot, rem;
>=20
>               quot =3D (cyc >> time_shift);
>               rem =3D cyc & ((1 << time_shift) - 1);
>               delta =3D time_offset + quot * time_mult +
>                       ((rem * time_mult) >> time_shift);
>=20
>               enabled +=3D delta;
>               if (idx)
>                       running +=3D delta;
>=20
>               quot =3D count / running;
>               rem =3D count % running;
>               count =3D quot * enabled + (rem * enabled) / running;
>       }
>=20
>       return count;
> }
>=20
> AFAICT:
> 1) The last clause is scaling the count up to allow for time when the hard=
ware counter
>  couldn't be allocated.
>  I'm not convinced that is useful, better to ignore the entire measurement=
.
>  Half this got deleted from the man page, leaving strange 'set but unused'=
 variables.
>=20
> 2) The hardware counters are disabled while the process is asleep.
>  On wake a different pmc counter might be used (maybe on a different cpu).=

>  The new cpu might not even have a counter available.
>=20
> 3) If you don't want to scale up for missing periods it is probably enough=
 to do:
>   do {
>       seq =3D pc->offset;
>       barrier();
>       idx =3D pc->index;
>       if (!index)
>           return -1;
>       count =3D pc->offset + rdpmc(idx - 1);
>   } while (seq !=3D pc->seq);
>   return (unsigned int)count;
>=20
> Not tried it yet :-)

Use my version :).  I just throw out the sample if we were preempted or if i=
t was otherwise suspicious.

=E2=80=94Andy

>=20
>   David
>=20
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1=
PT, UK
> Registration No: 1397386 (Wales)