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: <20090624084033.GA18713@elte.hu>
Date:	Wed, 24 Jun 2009 10:40:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jaswinder Singh Rajput <jaswinder@...nel.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip] perf_counter tools: shorten names for events


* Jaswinder Singh Rajput <jaswinder@...nel.org> wrote:

> On Tue, 2009-06-23 at 21:56 +0200, Ingo Molnar wrote:
> > * Jaswinder Singh Rajput <jaswinder@...nel.org> wrote:
> > 
> > > After :
> > > 
> > >  Performance counter stats for 'ls -lR /usr/include/':
> > > 
> > >       259250339  L1-d-load-refs        (scaled from 22.73%)
> > >         1187200  L1-d-load-miss        (scaled from 23.01%)
> > >          150454  L1-d-store-refs       (scaled from 23.01%)
> > >          494252  L1-d-prefetch-refs    (scaled from 23.29%)
> > >          362661  L1-d-prefetch-miss    (scaled from 23.73%)
> > >       247343449  L1-i-load-refs        (scaled from 23.71%)
> > >         4804990  L1-i-load-miss        (scaled from 23.85%)
> > >          108711  L1-i-prefetch-refs    (scaled from 23.83%)
> > >         6260313  L2-load-refs          (scaled from 23.82%)
> > >          605425  L2-load-miss          (scaled from 23.82%)
> > >         6898075  L2-store-refs         (scaled from 23.96%)
> > >       248334160  d-TLB-load-refs       (scaled from 23.95%)
> > >         3812835  d-TLB-load-miss       (scaled from 23.87%)
> > >       253208496  i-TLB-load-refs       (scaled from 23.73%)
> > >            5873  i-TLB-load-miss       (scaled from 23.46%)
> > >       110891027  Branch-load-refs      (scaled from 23.21%)
> > >         5529622  Branch-load-miss      (scaled from 23.02%)
> > 
> > here's an edited version of my suggestions:
> > 
> > >       259250339  dL1-loads              (scaled from 22.73%)
> > >         1187200  dL1-load-misses        (scaled from 23.01%)
> > >          150454  dL1-stores             (scaled from 23.01%)
> > >          494252  dL1-prefetches         (scaled from 23.29%)
> > >          362661  dL1-prefetch-misses    (scaled from 23.73%)
> > >       247343449  iL1-loads              (scaled from 23.71%)
> > >         4804990  iL1-load-misses        (scaled from 23.85%)
> > >          108711  iL1-prefetches         (scaled from 23.83%)
> > >         6260313  LLC-loads              (scaled from 23.82%)
> > >          605425  LLC-load-misses        (scaled from 23.82%)
> > >         6898075  LLC-stores             (scaled from 23.96%)
> > >       248334160  dTLB-loads             (scaled from 23.95%)
> > >         3812835  dTLB-load-misses       (scaled from 23.87%)
> > >       253208496  iTLB-loads             (scaled from 23.73%)
> > >            5873  iTLB-load-misses       (scaled from 23.46%)
> > >       110891027  branches               (scaled from 23.21%)
> > >         5529622  branch-misses          (scaled from 23.02%)
> > 
> > We can leave out 'refs' i think - without any qualification 
> > statements like '247343449 iL1-loads' are still unambigious i think.
> > 
> 
> Looks good.
> 
> > Plus we can abbreviate dL1/iL1/dTLB/iTLB. The capitalization 
> > matters. Also, note that it's LLC (Last Level Cache), not L2.
> > 
> > ( Sidenote: L2 can still be an alias for LLC, even though some CPUs 
> >   have a L3 too. )
> > 
> 
> Ok, I will fix it and also set the alias.
> 
> > Note, branches are special - we dont really have 'branch loads', 
> > branches are executions. 'Branches' and 'Branch-misses' are the 
> > right term.
> > 
> > Do you agree?
> > 
> 
> Event we used for (BPU, READ, ACCESS) is 'branch instructions 
> retired'
> 
> So 'branch loads' we mean 'branch instruction loaded and retired'
> 
> I like all of them : 'branch loads', 'branch retired' or 
> 'branches'

There's two things:

Firstly, there are "loads" are when data is loaded into the CPU. It 
has a very firm meaning.

Secondly, the "loading an instruction into the CPU" idiom you 
mention is not really correct - what we generally say is to "fetch 
an instruction".

In that sense using 'branch loads' is confusing, and that's why i 
corrected it. 'branches' is perfectly fine shortcut for 'branch 
instructions executed'. (or branch instructions fetched and retired)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ