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] [day] [month] [year] [list]
Message-ID: <CAP-5=fVf0K6RtLv-oGMbgr4uGE5hqBT5=EqArZF+_X0Sx3YhPA@mail.gmail.com>
Date: Mon, 5 Aug 2024 17:20:49 -0700
From: Ian Rogers <irogers@...gle.com>
To: "Wang, Weilin" <weilin.wang@...el.com>
Cc: Song Liu <song@...nel.org>, "Liang, Kan" <kan.liang@...ux.intel.com>, 
	"Taylor, Perry" <perry.taylor@...el.com>, "Baker, Edward" <edward.baker@...el.com>, 
	"Daneti, Venkata Naga Sai Dilip" <venkata.naga.sai.dilip.daneti@...el.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, "Hunter, Adrian" <adrian.hunter@...el.com>, 
	"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, 
	Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...nel.org>, 
	"jonesz@...a.com" <jonesz@...a.com>
Subject: Re: Some unc_cha_tor_* events appear to be "not supported"?

On Mon, Aug 5, 2024 at 1:26 PM Wang, Weilin <weilin.wang@...el.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Song Liu <song@...nel.org>
> > Sent: Monday, August 5, 2024 12:15 PM
> > To: Wang, Weilin <weilin.wang@...el.com>
> > Cc: Liang, Kan <kan.liang@...ux.intel.com>; Ian Rogers <irogers@...gle.com>;
> > Taylor, Perry <perry.taylor@...el.com>; Baker, Edward
> > <edward.baker@...el.com>; Daneti, Venkata Naga Sai Dilip
> > <venkata.naga.sai.dilip.daneti@...el.com>; Arnaldo Carvalho de Melo
> > <acme@...nel.org>; Hunter, Adrian <adrian.hunter@...el.com>; linux-perf-
> > users@...r.kernel.org; open list <linux-kernel@...r.kernel.org>; Namhyung
> > Kim <namhyung@...nel.org>; Jiri Olsa <jolsa@...nel.org>; jonesz@...a.com
> > Subject: Re: Some unc_cha_tor_* events appear to be "not supported"?
> >
> > Hi Weilin,
> >
> > On Mon, Aug 5, 2024 at 11:34 AM Wang, Weilin <weilin.wang@...el.com>
> > wrote:
> > [...]
> > > > > > > >
> > > > > > > > The value '4b433' is for the 'Filter1', according to the original event
> > > > > > > > list.
> > > > > > > >
> > > > > > > >
> > >
> > > @Song Liu, do you see different output from some other
> > unc_cha_tor_occupancy
> > > and unc_cha_tor_inserts events. Or, are all of them report the same warning
> > like this
> > > example here?
> > >
> > > Could you please try UNC_CHA_TOR_OCCUPANCY.IA_MISS and share the
> > output?
> > > Please also specify the platform you tested on. Thanks!
> >
> > This event is working, I guess. Though the output is zero on the host.
> >
> > [root@ ~]# perf stat -e  UNC_CHA_TOR_OCCUPANCY.IA_MISS -a -- sleep 1
> >
> >  Performance counter stats for 'system wide':
> >
> >                  0      UNC_CHA_TOR_OCCUPANCY.IA_MISS
> >
> >        1.002497126 seconds time elapsed
> >
> > For this one, I am testing on Intel(R) Xeon(R) D-2191A CPU @ 1.60GHz.
> > I think the issue happens on all skylake and copperlake CPUs.
>
> This looks correct. I thinks some of this type of events are supposed to be always
> return 0.
>
> >
> > >
> > > > > >
> > > >
> > https://github.com/intel/perfmon/blob/main/SKX/events/skylakex_uncore.js
> > > > > > on#L4634
> > > > > > > >
> > > > > > > >       "EventName":
> > "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
> > > > > > > >       "BriefDescription":
> > > > > > "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
> > > > > > > >       "PublicDescription":
> > > > > > "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
> > > > > > > >       "Counter": "0",
> > > > > > > >       "MSRValue": "0x00",
> > > > > > > >       "ELLC": "0",
> > > > > > > >       "Filter": "Filter1",
> > > > > > > >       "ExtSel": "0",
> > > > > > > >       "Deprecated": "0",
> > > > > > > >       "FILTER_VALUE": "0x4b433"
> > > > > > > >
> > > > > > > > There are two filters for CHA on SKX. Each filter is 32 bits wide.
> > > > > > > > So the Linux kernel driver uses config1 (64 bits wide) to represent
> > both
> > > > > > > > of them. The low 32 bits are for filter0 and high 32 bits are for
> > filter1.
> > > > > > > >
> > > > > > > > It should be an issue of the convert script, which set the filter1 value
> > > > > > > > to the low 32 bits.
> > >
> > > @Liang, Kan, the following is the converted
> > "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD"
> > > in perf JSON. The "Filter" filed has value "config1=0x4b433", which looks
> > correct to
> > > me according to your description above.
> > >
> > > Please let me know your thoughts.
> > >
> > >     {
> > >         "BriefDescription": "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
> > >         "Counter": "0",
> > >         "EventCode": "0x36",
> > >         "EventName": "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
> > >         "Filter": "config1=0x4b433",
> > >         "PerPkg": "1",
> > >         "UMask": "0x21",
> > >         "Unit": "CHA"
> > >     },
> >
> > I think we need config1 to be 0x4b43300000000?
>
> If this is the value required, @Liang, Kan and @Ian Rogers, should we update the
> converter script to set 0x4b43300000000 or let kernel to pad the zeros? I want to
> ensure that we won't break other platforms if change this in the converter script.

I think updating the converter script to do this would be good.
Generally it is a bad idea in an event to use config, config1, etc.
the reason being that the driver may decide to move the meaning of
bits around and then that breaks the event if the bit positions in
config are hard coded. This is skylakex and so rewriting the driver is
unlikely to happen, but the fix would apply to cascadelakex and
snowridgex too, so maybe..

From:
```
$ grep -r config1 /sys/devices/uncore_cha_0/format/
/sys/devices/uncore_cha_0/format/filter_rem:config1:32
/sys/devices/uncore_cha_0/format/filter_opc0:config1:41-50
/sys/devices/uncore_cha_0/format/filter_isoc:config1:63
/sys/devices/uncore_cha_0/format/filter_tid:config1:0-8
/sys/devices/uncore_cha_0/format/filter_loc:config1:33
/sys/devices/uncore_cha_0/format/filter_nc:config1:62
/sys/devices/uncore_cha_0/format/filter_opc1:config1:51-60
/sys/devices/uncore_cha_0/format/filter_all_op:config1:35
/sys/devices/uncore_cha_0/format/filter_not_nm:config1:37
/sys/devices/uncore_cha_0/format/filter_state:config1:17-26
/sys/devices/uncore_cha_0/format/filter_nm:config1:36
```
we can see the meanings of the bit positions. So the best encoding of
0x4b433 in the event I think would be:
cha/event=0x36,umask=0x21,filter_rem=1,filter_loc=1,filter_nm=1,filter_not_nm=1,filter_opc0=0x5a,filter_opc1=1/

I wonder in the perfmon json, could we instead of:
 "FILTER_VALUE": "0x4b433"
have individual values for each of the filter values? So something like:

Before:
    {
      "Unit": "CHA",
      "EventCode": "0x36",
      "UMask": "0x21",
      "PortMask": "0x00",
      "FCMask": "0x00",
      "UMaskExt": "0x00",
      "EventName": "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
      "BriefDescription": "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
      "PublicDescription": "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
      "Counter": "0",
      "MSRValue": "0x00",
      "ELLC": "0",
      "Filter": "Filter1",
      "ExtSel": "0",
      "Deprecated": "0",
      "FILTER_VALUE": "0x4b433"
    },

After:
    {
      "Unit": "CHA",
      "EventCode": "0x36",
      "UMask": "0x21",
      "PortMask": "0x00",
      "FCMask": "0x00",
      "UMaskExt": "0x00",
      "EventName": "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
      "BriefDescription": "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
      "PublicDescription": "UNC_CHA_TOR_OCCUPANCY.IA_MISS_LlcPrefDRD",
      "Counter": "0",
      "MSRValue": "0x00",
      "ELLC": "0",
      "FilterLoc": "1",
      "FilterRem": "1",
      "FilterNm": "1",
      "FilterNotNm": "1",
      "FilterOpc0": "0x5a",
      "FilterOpc1": "1",
      "ExtSel": "0",
      "Deprecated": "0",
    },

Then in the converter script we can just read and concatenate the values.

Thanks,
Ian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ