Hi,
The stable kernel 4.9.112 has supported Intel uncore feature in perf core. While it also needs the perf tool supporting to let perf uncore feature work.
Following backport patches enables basic perf uncore feature in 4.9.112.
For example, on skylake desktop,
root@skl:~# uname -a Linux skl 4.9.112+ #2 SMP Mon Jul 16 17:35:25 CST 2018 x86_64 x86_64 x86_64 GNU/Linux
root@skl:~# perf list | grep unc_ unc_arb_coh_trk_requests.all unc_arb_trk_occupancy.all unc_arb_trk_occupancy.cycles_with_any_request unc_arb_trk_requests.all unc_arb_trk_requests.drd_direct unc_arb_trk_requests.writes unc_cbo_cache_lookup.any_es unc_cbo_cache_lookup.any_i unc_cbo_cache_lookup.any_m unc_cbo_cache_lookup.any_mesi unc_cbo_cache_lookup.read_es unc_cbo_cache_lookup.read_i unc_cbo_cache_lookup.read_mesi unc_cbo_cache_lookup.write_es unc_cbo_cache_lookup.write_m unc_cbo_cache_lookup.write_mesi unc_cbo_xsnp_response.hit_xcore unc_cbo_xsnp_response.hitm_xcore unc_cbo_xsnp_response.miss_eviction unc_cbo_xsnp_response.miss_xcore
root@skl:~# perf stat -a -e unc_cbo_cache_lookup.any_es sleep 1
Performance counter stats for 'system wide':
147,229 unc_cbo_cache_lookup.any_es
1.001204726 seconds time elapsed
These patches are divided into 2 parts, perf core part and perf tool part. (Please apply the patches from top to bottom in following lists, otherwise conflicts will happen)
1. Patches for perf core to fix some uncore issues.
perf/x86/intel/uncore: Fix Skylake server CHA LLC_LOOKUP event umask c3f02682a101b83424128915b14e60c156c03f02
perf/x86/intel/uncore: Fix Skylake server PCU PMU event format bab4e569e80c07ba6fe5e4f2d815adeef26cee94
perf/x86/intel/uncore: Fix Skylake UPI PMU event masks b3625980a65db6b6b6bbd5790a77ab95ce6397c5
perf/x86/intel/uncore: Remove invalid Skylake server CHA filter field 9ad0fbd8fcd9e6815908c772f8d792a9d764449e
perf/x86/intel/uncore: Fix SKX CHA event extra regs 8aa7b7b4b4a601978672dce6604b9f5630b2eeb8
perf/x86/intel/uncore: Fix missing marker for skx_uncore_cha_extra_regs ba883b4abc9cd837441b01eb9cf8d9196181294d
perf/x86/intel/uncore: Add event constraint for BDX PCU bb9fbe1b57503f790dbbf9f06e72cb0fb9e60740
2. Patches for perf tool to enable the uncore feature.
Note that since some dependencies in perf vendor events patches, so this patch-set includes both core and uncore event patches.
perf vendor events: Add BroadwellDE V5 event file 27b565b1eb04a277027953cab13b5aad5d469390
perf vendor events: Add Broadwell V17 event file b74d1315cab113ce1e0ee5e10eb6638219c1b0d1
perf vendor events: Add BroadwellX V10 event file 19c0389b60d486010d508d5a1551ee9b6a8b2f45
perf vendor events: Add Bonnell V4 event file 052aa3cce3f2b91e339318e5fe9806d0cfd822f0
perf vendor events: Add Goldmont V8 event file 4a00680b059a6c2c378945e2dffa2fa2876a4fc1
perf vendor events: Add Haswell V24 event file dcfbad10c7ba0bd2f4993c8d8a258471eb6083ff
perf vendor events: Add HaswellX V17 event file ede007404388cd1ba306760a2881dc9722f5bb47
perf vendor events: Add IvyBridge V18 event file 4b90798ebb0bab8fe1ed9065e80879503f5601d2
perf vendor events: Add IvyTown V19 event file d910f0ba6d72a0917ae30b6aed5131988e3096e4
perf vendor events: Add Jaketown V20 event file 902ea4ee33e6dccece0f78a68e882eee9be9577f
perf vendor events: Add KnightsLanding V9 event file 55d42d272ee30cd781e74a9c4ab152664c6417fc
perf vendor events: Add NehalemEP V2 event file edaa78b4c050ec0a0fc7f436cdf6a73c91af64e0
perf vendor events: Add NehalemEX V2 event file d8c303858582d4dcd90f13ebbe9db812a70d0948
perf vendor events: Add Skylake V24 event file 47cbd67e243a6bbb4133d719edd24ee6a315462d
perf vendor events: Add Silvermont V13 event file 1b0978458300164046d12e1b7930c9de38057e1d
perf vendor events: Add SandyBridge V15 event file 6e82bdae472355fe0953e12eb29a36079e155ddb
perf vendor events: Add WestmereEP-DP V2 event file 1f888acd92c8f88b0ab9640cef0794bc5424c668
perf vendor events: Add WestmereEP-SP V2 event file 01dd25455b3588431d3f59c70e7b934a91d66121
perf vendor events: Add WestmereEX V2 event file 1fbd54b2e2356659f9f87920dc514792db6ff602
perf vendor events intel: Add uncore events for Haswell Server processor 7003f00fdb7b44662e8b47ebaf8ff6ce554df4bb
perf vendor events intel: Add uncore events for Broadwell Server 949c84efcac9662b1df520675cdfce07273f4d59
perf vendor events intel: Add uncore events for IvyBridge Server 6b138c7b14d6134bed2419ccf7573b87e7a064b0
perf vendor events intel: Add uncore events for Sandy Bridge Server dd32cb5d8fd42316bf8c2b9f7e5c51a38625f755
perf vendor events intel: Add uncore events for Xeon Phi (Knights Landing) 22c8e5526b7bf33840c20b4e717e6560e5dfb294
perf vendor events intel: Add uncore events for Broadwell DE 76667024171a2d6811c5ddbe42a8f675987ad8a1
perf vendor events: Add mapping for KnightsMill PMU events 771ceddaadd0a2b31603034b36dca50943ff6836
perf vendor events intel: Update Intel uncore JSON event files b90b3e9c11050e09279d2b9a318189e155910b20
perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell DE uncore 9c4e2e2589c99ed01db6245847b4bd44bc053330
perf vendor events intel: Add uncore events for Sandy Bridge client 80432c7311dbcf0c814d4923480b055a725b0be2
perf vendor events intel: Add uncore events for Ivy Bridge client bccdcb2a77ba0bef17baf152179e30ca35459a0c
perf vendor events intel: Add uncore events for Haswell client 0585c6265e66f952bcb6280cf078e5e120bd367a
perf vendor events intel: Add uncore events for Broadwell client 092a95d41655bdd31d7d28f1788818724505feb2
perf vendor events intel: Add uncore events for Skylake client 92c6de0f10a80e4936fac04148bd3783a7c2b9f8
perf vendor events: Add core event list for Skylake Server 630171d4156a257869b3cca5b2e63aacf7bc7948
perf vendor events: Add Skylake server uncore event list 41d3d6db1767326dd7daf7c6df48e42020647c15
perf vendor events: Add Goldmont Plus V1 event file 65db92e0965ab56e8031d5c804f26d5be0e47047
perf jevents: Parse eventcode as number d581141970ef3965c1624960fa928d765afd8a3e
perf jevents: Add support for parsing uncore json files fedb2b518239cbc00abcf0d200e0be8436251c11
perf pmu: Support per pmu json aliases 15b22ed369aa23ef4d083ffb9621650c353d3ddd
perf pmu: Support event aliases for non cpu// pmus 231bb2aa32498cbebef1306889a02114e9dfc934
perf pmu: Factor out scale conversion code d02fc6bcd53721cf8588633409157c232f2418e0
perf tools: Move new_term arguments into struct parse_events_term template 67b49b38f7bd6f34319b540ce824d5697241b3a8
perf tools: Fail on using multiple bits long terms without value 99e7138eb7897aa0ccc6661173ae2d7e79721e05
perf list: Add debug support for outputing alias string f23610245c1aa0e912476e642bd5107d04122230
perf tools: Factor out PMU matching in parser 2073ad3326b7e4577af3d6789edd03df79519d21
perf pmu: Expand PMU events by prefix match 8255718f4bedbfb3558fba10ff40a70934f2117d
perf pmu: Special case uncore_ prefix a820e33547aee9fd0460106c1fc577a125c23975
perf stat: Factor out callback for collecting event values fbe51fba82901fd15d3e0a068388fcd7d02dc047
perf stat: Collapse identically named events 430daf2dc7aff16096a137347e6fd03d4af609e9
perf stat: Handle partially bad results with merging b4229e9d4cac2295f8f04ec26acd571a391c6c37
perf vendor events intel: Add uncore_arb JSON support af34cb4fad1ba08db199ef1b0a529549e041dd25
perf vendor events intel: Add missing space in json descriptions 3401e8d1e1300742ed41910b9338b9da52689a16
Thanks Jin Yao
On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote:
Hi,
The stable kernel 4.9.112 has supported Intel uncore feature in perf core. While it also needs the perf tool supporting to let perf uncore feature work.
Following backport patches enables basic perf uncore feature in 4.9.112.
For example, on skylake desktop,
Why would anyone care about this on a "desktop" for 4.9? No one should be using 4.9.y on a desktop anymore, it's over 2 years old, why would they expect any "new" hardware support to work for them? Why can't they just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 year old kernel.
Heck, servers shouldn't either, but that's a totally different rant. However, for hardware that is newer than the base kernel version release, I have no sympathy. Just use a newer kernel, right?
What distro relies on a 4.9 kernel for brand new hardware that does not already support a newer kernel release for such hardware?
root@skl:~# uname -a Linux skl 4.9.112+ #2 SMP Mon Jul 16 17:35:25 CST 2018 x86_64 x86_64 x86_64 GNU/Linux
root@skl:~# perf list | grep unc_ unc_arb_coh_trk_requests.all unc_arb_trk_occupancy.all unc_arb_trk_occupancy.cycles_with_any_request unc_arb_trk_requests.all unc_arb_trk_requests.drd_direct unc_arb_trk_requests.writes unc_cbo_cache_lookup.any_es unc_cbo_cache_lookup.any_i unc_cbo_cache_lookup.any_m unc_cbo_cache_lookup.any_mesi unc_cbo_cache_lookup.read_es unc_cbo_cache_lookup.read_i unc_cbo_cache_lookup.read_mesi unc_cbo_cache_lookup.write_es unc_cbo_cache_lookup.write_m unc_cbo_cache_lookup.write_mesi unc_cbo_xsnp_response.hit_xcore unc_cbo_xsnp_response.hitm_xcore unc_cbo_xsnp_response.miss_eviction unc_cbo_xsnp_response.miss_xcore
root@skl:~# perf stat -a -e unc_cbo_cache_lookup.any_es sleep 1
Performance counter stats for 'system wide':
147,229 unc_cbo_cache_lookup.any_es 1.001204726 seconds time elapsedThese patches are divided into 2 parts, perf core part and perf tool part. (Please apply the patches from top to bottom in following lists, otherwise conflicts will happen)
- Patches for perf core to fix some uncore issues.
perf/x86/intel/uncore: Fix Skylake server CHA LLC_LOOKUP event umask c3f02682a101b83424128915b14e60c156c03f02
perf/x86/intel/uncore: Fix Skylake server PCU PMU event format bab4e569e80c07ba6fe5e4f2d815adeef26cee94
perf/x86/intel/uncore: Fix Skylake UPI PMU event masks b3625980a65db6b6b6bbd5790a77ab95ce6397c5
perf/x86/intel/uncore: Remove invalid Skylake server CHA filter field 9ad0fbd8fcd9e6815908c772f8d792a9d764449e
perf/x86/intel/uncore: Fix SKX CHA event extra regs 8aa7b7b4b4a601978672dce6604b9f5630b2eeb8
perf/x86/intel/uncore: Fix missing marker for skx_uncore_cha_extra_regs ba883b4abc9cd837441b01eb9cf8d9196181294d
perf/x86/intel/uncore: Add event constraint for BDX PCU bb9fbe1b57503f790dbbf9f06e72cb0fb9e60740
- Patches for perf tool to enable the uncore feature.
Note that since some dependencies in perf vendor events patches, so this patch-set includes both core and uncore event patches.
perf vendor events: Add BroadwellDE V5 event file 27b565b1eb04a277027953cab13b5aad5d469390
perf vendor events: Add Broadwell V17 event file b74d1315cab113ce1e0ee5e10eb6638219c1b0d1
perf vendor events: Add BroadwellX V10 event file 19c0389b60d486010d508d5a1551ee9b6a8b2f45
perf vendor events: Add Bonnell V4 event file 052aa3cce3f2b91e339318e5fe9806d0cfd822f0
perf vendor events: Add Goldmont V8 event file 4a00680b059a6c2c378945e2dffa2fa2876a4fc1
perf vendor events: Add Haswell V24 event file dcfbad10c7ba0bd2f4993c8d8a258471eb6083ff
perf vendor events: Add HaswellX V17 event file ede007404388cd1ba306760a2881dc9722f5bb47
perf vendor events: Add IvyBridge V18 event file 4b90798ebb0bab8fe1ed9065e80879503f5601d2
perf vendor events: Add IvyTown V19 event file d910f0ba6d72a0917ae30b6aed5131988e3096e4
perf vendor events: Add Jaketown V20 event file 902ea4ee33e6dccece0f78a68e882eee9be9577f
perf vendor events: Add KnightsLanding V9 event file 55d42d272ee30cd781e74a9c4ab152664c6417fc
perf vendor events: Add NehalemEP V2 event file edaa78b4c050ec0a0fc7f436cdf6a73c91af64e0
perf vendor events: Add NehalemEX V2 event file d8c303858582d4dcd90f13ebbe9db812a70d0948
perf vendor events: Add Skylake V24 event file 47cbd67e243a6bbb4133d719edd24ee6a315462d
perf vendor events: Add Silvermont V13 event file 1b0978458300164046d12e1b7930c9de38057e1d
perf vendor events: Add SandyBridge V15 event file 6e82bdae472355fe0953e12eb29a36079e155ddb
perf vendor events: Add WestmereEP-DP V2 event file 1f888acd92c8f88b0ab9640cef0794bc5424c668
perf vendor events: Add WestmereEP-SP V2 event file 01dd25455b3588431d3f59c70e7b934a91d66121
perf vendor events: Add WestmereEX V2 event file 1fbd54b2e2356659f9f87920dc514792db6ff602
perf vendor events intel: Add uncore events for Haswell Server processor 7003f00fdb7b44662e8b47ebaf8ff6ce554df4bb
perf vendor events intel: Add uncore events for Broadwell Server 949c84efcac9662b1df520675cdfce07273f4d59
perf vendor events intel: Add uncore events for IvyBridge Server 6b138c7b14d6134bed2419ccf7573b87e7a064b0
perf vendor events intel: Add uncore events for Sandy Bridge Server dd32cb5d8fd42316bf8c2b9f7e5c51a38625f755
perf vendor events intel: Add uncore events for Xeon Phi (Knights Landing) 22c8e5526b7bf33840c20b4e717e6560e5dfb294
perf vendor events intel: Add uncore events for Broadwell DE 76667024171a2d6811c5ddbe42a8f675987ad8a1
perf vendor events: Add mapping for KnightsMill PMU events 771ceddaadd0a2b31603034b36dca50943ff6836
perf vendor events intel: Update Intel uncore JSON event files b90b3e9c11050e09279d2b9a318189e155910b20
perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell DE uncore 9c4e2e2589c99ed01db6245847b4bd44bc053330
perf vendor events intel: Add uncore events for Sandy Bridge client 80432c7311dbcf0c814d4923480b055a725b0be2
perf vendor events intel: Add uncore events for Ivy Bridge client bccdcb2a77ba0bef17baf152179e30ca35459a0c
perf vendor events intel: Add uncore events for Haswell client 0585c6265e66f952bcb6280cf078e5e120bd367a
perf vendor events intel: Add uncore events for Broadwell client 092a95d41655bdd31d7d28f1788818724505feb2
perf vendor events intel: Add uncore events for Skylake client 92c6de0f10a80e4936fac04148bd3783a7c2b9f8
perf vendor events: Add core event list for Skylake Server 630171d4156a257869b3cca5b2e63aacf7bc7948
perf vendor events: Add Skylake server uncore event list 41d3d6db1767326dd7daf7c6df48e42020647c15
perf vendor events: Add Goldmont Plus V1 event file 65db92e0965ab56e8031d5c804f26d5be0e47047
perf jevents: Parse eventcode as number d581141970ef3965c1624960fa928d765afd8a3e
perf jevents: Add support for parsing uncore json files fedb2b518239cbc00abcf0d200e0be8436251c11
perf pmu: Support per pmu json aliases 15b22ed369aa23ef4d083ffb9621650c353d3ddd
perf pmu: Support event aliases for non cpu// pmus 231bb2aa32498cbebef1306889a02114e9dfc934
perf pmu: Factor out scale conversion code d02fc6bcd53721cf8588633409157c232f2418e0
perf tools: Move new_term arguments into struct parse_events_term template 67b49b38f7bd6f34319b540ce824d5697241b3a8
perf tools: Fail on using multiple bits long terms without value 99e7138eb7897aa0ccc6661173ae2d7e79721e05
perf list: Add debug support for outputing alias string f23610245c1aa0e912476e642bd5107d04122230
perf tools: Factor out PMU matching in parser 2073ad3326b7e4577af3d6789edd03df79519d21
perf pmu: Expand PMU events by prefix match 8255718f4bedbfb3558fba10ff40a70934f2117d
perf pmu: Special case uncore_ prefix a820e33547aee9fd0460106c1fc577a125c23975
perf stat: Factor out callback for collecting event values fbe51fba82901fd15d3e0a068388fcd7d02dc047
perf stat: Collapse identically named events 430daf2dc7aff16096a137347e6fd03d4af609e9
perf stat: Handle partially bad results with merging b4229e9d4cac2295f8f04ec26acd571a391c6c37
perf vendor events intel: Add uncore_arb JSON support af34cb4fad1ba08db199ef1b0a529549e041dd25
perf vendor events intel: Add missing space in json descriptions 3401e8d1e1300742ed41910b9338b9da52689a16
What is the overall diffstat of all of these changes?
thanks,
greg k-h
On Wed, Jul 18, 2018 at 11:29:50AM +0200, Greg KH wrote:
On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote:
Hi,
The stable kernel 4.9.112 has supported Intel uncore feature in perf core. While it also needs the perf tool supporting to let perf uncore feature work.
Following backport patches enables basic perf uncore feature in 4.9.112.
For example, on skylake desktop,
Why would anyone care about this on a "desktop" for 4.9? No one should be using 4.9.y on a desktop anymore, it's over 2 years old, why would they expect any "new" hardware support to work for them? Why can't they
It's actually not new hardware support: Skylake is fairly old hardware at this point.
just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 year old kernel.
Heck, servers shouldn't either, but that's a totally different rant.
These chips are not only used in desktops but also in servers.
However, for hardware that is newer than the base kernel version release, I have no sympathy. Just use a newer kernel, right?
We have customers which are on old kernels with new hardware. The backports happen either way. This is just an attempt to do it in a coordinated fashion.
What distro relies on a 4.9 kernel for brand new hardware that does not already support a newer kernel release for such hardware?
None afaik, but there is a lot of Linux use beyond distros.
-Andi
On Wed, Jul 18, 2018 at 10:09:44AM -0700, Andi Kleen wrote:
On Wed, Jul 18, 2018 at 11:29:50AM +0200, Greg KH wrote:
On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote:
Hi,
The stable kernel 4.9.112 has supported Intel uncore feature in perf core. While it also needs the perf tool supporting to let perf uncore feature work.
Following backport patches enables basic perf uncore feature in 4.9.112.
For example, on skylake desktop,
Why would anyone care about this on a "desktop" for 4.9? No one should be using 4.9.y on a desktop anymore, it's over 2 years old, why would they expect any "new" hardware support to work for them? Why can't they
It's actually not new hardware support: Skylake is fairly old hardware at this point.
So is 4.9. I don't understand your point. The hardware is obviously newer than 4.9 was, otherwise the support for it would already be in there, right?
just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 year old kernel.
Heck, servers shouldn't either, but that's a totally different rant.
These chips are not only used in desktops but also in servers.
This was asked for with regards to desktops, so now I'm confused. Exactly who/what is going to be needing/wanting/using these changes?
However, for hardware that is newer than the base kernel version release, I have no sympathy. Just use a newer kernel, right?
We have customers which are on old kernels with new hardware.
That's obviously not a wise thing to do for lots of good reasons. This exact example being a huge one (i.e. you can't go back in time and add support for hardware that was not out yet.)
The backports happen either way. This is just an attempt to do it in a coordinated fashion.
There was no coordination here, just a list of git commit ids. Which is great, and all that is really needed, but I'm confused as to who is trying to coordinate with who?
What distro relies on a 4.9 kernel for brand new hardware that does not already support a newer kernel release for such hardware?
None afaik, but there is a lot of Linux use beyond distros.
So no distro uses this, which makes me really wonder who would be the user of these backports. And for how long? Why are these people not moving to 4.14 already given that the published date for 4.9 end-of-life is getting very close. Are you expecting to be rescued by Google again?
That can't be true as Android doesn't care about x86 servers :)
Please provide real solid information, including the answer to the other question I asked in my response, which was not included here for some reason.
thanks,
greg k-h
On 7/19/2018 1:39 AM, Greg KH wrote:
On Wed, Jul 18, 2018 at 10:09:44AM -0700, Andi Kleen wrote:
On Wed, Jul 18, 2018 at 11:29:50AM +0200, Greg KH wrote:
On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote:
Hi,
The stable kernel 4.9.112 has supported Intel uncore feature in perf core. While it also needs the perf tool supporting to let perf uncore feature work.
Following backport patches enables basic perf uncore feature in 4.9.112.
For example, on skylake desktop,
Why would anyone care about this on a "desktop" for 4.9? No one should be using 4.9.y on a desktop anymore, it's over 2 years old, why would they expect any "new" hardware support to work for them? Why can't they
It's actually not new hardware support: Skylake is fairly old hardware at this point.
So is 4.9. I don't understand your point. The hardware is obviously newer than 4.9 was, otherwise the support for it would already be in there, right?
just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 year old kernel.
Heck, servers shouldn't either, but that's a totally different rant.
These chips are not only used in desktops but also in servers.
This was asked for with regards to desktops, so now I'm confused. Exactly who/what is going to be needing/wanting/using these changes?
This patchset is not only regarding to desktop but also for servers. Sorry, my example in patch description brings confusion.
The patchset supports the server like Skylake, and it also supports some old servers, for example, Broadwell and Haswell.
4.9 kernel has uncore patches yet but at the perf tool side it doesn't have associated uncore patches, so actually the perf uncore feature doesn't work in 4.9.
We just want to enable the perf uncore feature in 4.9, it's especially useful for server performance analysis.
Thanks Jin Yao
However, for hardware that is newer than the base kernel version release, I have no sympathy. Just use a newer kernel, right?
We have customers which are on old kernels with new hardware.
That's obviously not a wise thing to do for lots of good reasons. This exact example being a huge one (i.e. you can't go back in time and add support for hardware that was not out yet.)
The backports happen either way. This is just an attempt to do it in a coordinated fashion.
There was no coordination here, just a list of git commit ids. Which is great, and all that is really needed, but I'm confused as to who is trying to coordinate with who?
What distro relies on a 4.9 kernel for brand new hardware that does not already support a newer kernel release for such hardware?
None afaik, but there is a lot of Linux use beyond distros.
So no distro uses this, which makes me really wonder who would be the user of these backports. And for how long? Why are these people not moving to 4.14 already given that the published date for 4.9 end-of-life is getting very close. Are you expecting to be rescued by Google again?
That can't be true as Android doesn't care about x86 servers :)
Please provide real solid information, including the answer to the other question I asked in my response, which was not included here for some reason.
thanks,
greg k-h
On 7/19/2018 1:39 AM, Greg KH wrote:
On Wed, Jul 18, 2018 at 10:09:44AM -0700, Andi Kleen wrote:
On Wed, Jul 18, 2018 at 11:29:50AM +0200, Greg KH wrote:
On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote:
Hi,
The stable kernel 4.9.112 has supported Intel uncore feature in perf core. While it also needs the perf tool supporting to let perf uncore feature work.
Following backport patches enables basic perf uncore feature in 4.9.112.
For example, on skylake desktop,
Why would anyone care about this on a "desktop" for 4.9? No one should be using 4.9.y on a desktop anymore, it's over 2 years old, why would they expect any "new" hardware support to work for them? Why can't they
It's actually not new hardware support: Skylake is fairly old hardware at this point.
So is 4.9. I don't understand your point. The hardware is obviously newer than 4.9 was, otherwise the support for it would already be in there, right?
just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 year old kernel.
Heck, servers shouldn't either, but that's a totally different rant.
These chips are not only used in desktops but also in servers.
This was asked for with regards to desktops, so now I'm confused. Exactly who/what is going to be needing/wanting/using these changes?
However, for hardware that is newer than the base kernel version release, I have no sympathy. Just use a newer kernel, right?
We have customers which are on old kernels with new hardware.
That's obviously not a wise thing to do for lots of good reasons. This exact example being a huge one (i.e. you can't go back in time and add support for hardware that was not out yet.)
The backports happen either way. This is just an attempt to do it in a coordinated fashion.
There was no coordination here, just a list of git commit ids. Which is great, and all that is really needed, but I'm confused as to who is trying to coordinate with who?
What distro relies on a 4.9 kernel for brand new hardware that does not already support a newer kernel release for such hardware?
None afaik, but there is a lot of Linux use beyond distros.
So no distro uses this, which makes me really wonder who would be the user of these backports. And for how long? Why are these people not moving to 4.14 already given that the published date for 4.9 end-of-life is getting very close. Are you expecting to be rescued by Google again?
Hi Greg,
We do see 4.9 is now used by Alibaba.
Ali kernel is opensourced at https://github.com/alibaba/alikernel
Thanks Jin Yao
That can't be true as Android doesn't care about x86 servers :)
Please provide real solid information, including the answer to the other question I asked in my response, which was not included here for some reason.
thanks,
greg k-h
On Mon, Aug 06, 2018 at 08:46:32AM +0800, Jin, Yao wrote:
On 7/19/2018 1:39 AM, Greg KH wrote:
On Wed, Jul 18, 2018 at 10:09:44AM -0700, Andi Kleen wrote:
On Wed, Jul 18, 2018 at 11:29:50AM +0200, Greg KH wrote:
On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote:
Hi,
The stable kernel 4.9.112 has supported Intel uncore feature in perf core. While it also needs the perf tool supporting to let perf uncore feature work.
Following backport patches enables basic perf uncore feature in 4.9.112.
For example, on skylake desktop,
Why would anyone care about this on a "desktop" for 4.9? No one should be using 4.9.y on a desktop anymore, it's over 2 years old, why would they expect any "new" hardware support to work for them? Why can't they
It's actually not new hardware support: Skylake is fairly old hardware at this point.
So is 4.9. I don't understand your point. The hardware is obviously newer than 4.9 was, otherwise the support for it would already be in there, right?
just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 year old kernel.
Heck, servers shouldn't either, but that's a totally different rant.
These chips are not only used in desktops but also in servers.
This was asked for with regards to desktops, so now I'm confused. Exactly who/what is going to be needing/wanting/using these changes?
However, for hardware that is newer than the base kernel version release, I have no sympathy. Just use a newer kernel, right?
We have customers which are on old kernels with new hardware.
That's obviously not a wise thing to do for lots of good reasons. This exact example being a huge one (i.e. you can't go back in time and add support for hardware that was not out yet.)
The backports happen either way. This is just an attempt to do it in a coordinated fashion.
There was no coordination here, just a list of git commit ids. Which is great, and all that is really needed, but I'm confused as to who is trying to coordinate with who?
What distro relies on a 4.9 kernel for brand new hardware that does not already support a newer kernel release for such hardware?
None afaik, but there is a lot of Linux use beyond distros.
So no distro uses this, which makes me really wonder who would be the user of these backports. And for how long? Why are these people not moving to 4.14 already given that the published date for 4.9 end-of-life is getting very close. Are you expecting to be rescued by Google again?
Hi Greg,
We do see 4.9 is now used by Alibaba.
Ali kernel is opensourced at https://github.com/alibaba/alikernel
Ok, does this user require these patches? Do they have them in their kernel already? Do they need me to add them before they can use the hardware they already have? I don't understand the connection here...
And why did no one answer all of my questions from my first email?
greg k-h
On 8/7/2018 9:09 PM, Greg KH wrote:
On Mon, Aug 06, 2018 at 08:46:32AM +0800, Jin, Yao wrote:
On 7/19/2018 1:39 AM, Greg KH wrote:
On Wed, Jul 18, 2018 at 10:09:44AM -0700, Andi Kleen wrote:
On Wed, Jul 18, 2018 at 11:29:50AM +0200, Greg KH wrote:
On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote:
Hi,
The stable kernel 4.9.112 has supported Intel uncore feature in perf core. While it also needs the perf tool supporting to let perf uncore feature work.
Following backport patches enables basic perf uncore feature in 4.9.112.
For example, on skylake desktop,
Why would anyone care about this on a "desktop" for 4.9? No one should be using 4.9.y on a desktop anymore, it's over 2 years old, why would they expect any "new" hardware support to work for them? Why can't they
It's actually not new hardware support: Skylake is fairly old hardware at this point.
So is 4.9. I don't understand your point. The hardware is obviously newer than 4.9 was, otherwise the support for it would already be in there, right?
just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 year old kernel.
Heck, servers shouldn't either, but that's a totally different rant.
These chips are not only used in desktops but also in servers.
This was asked for with regards to desktops, so now I'm confused. Exactly who/what is going to be needing/wanting/using these changes?
However, for hardware that is newer than the base kernel version release, I have no sympathy. Just use a newer kernel, right?
We have customers which are on old kernels with new hardware.
That's obviously not a wise thing to do for lots of good reasons. This exact example being a huge one (i.e. you can't go back in time and add support for hardware that was not out yet.)
The backports happen either way. This is just an attempt to do it in a coordinated fashion.
There was no coordination here, just a list of git commit ids. Which is great, and all that is really needed, but I'm confused as to who is trying to coordinate with who?
What distro relies on a 4.9 kernel for brand new hardware that does not already support a newer kernel release for such hardware?
None afaik, but there is a lot of Linux use beyond distros.
So no distro uses this, which makes me really wonder who would be the user of these backports. And for how long? Why are these people not moving to 4.14 already given that the published date for 4.9 end-of-life is getting very close. Are you expecting to be rescued by Google again?
Hi Greg,
We do see 4.9 is now used by Alibaba.
Ali kernel is opensourced at https://github.com/alibaba/alikernel
Ok, does this user require these patches? Do they have them in their kernel already? Do they need me to add them before they can use the hardware they already have? I don't understand the connection here...
Hi Greg,
Ali needs the uncore patches and they have backported to their tree. So for adding uncore patches to stable tree, just neutral for them.
I wish to show that 4.9 is being used by some customers.
And why did no one answer all of my questions from my first email?
Sorry about that. I just answer part of questions, for example, "The patchset supports the server like Skylake, and it also supports some old servers, for example, Broadwell and Haswell, .....". I want to represent that it's not only for new hardware like SKL but also for some old hardware which may run with 4.9.
But for other questions, such as, who uses 4.9 in desktop, what distros need 4.9. I'm sorry I don't really know the answers so I don't reply. Sorry about that.
Thanks Jin Yao
greg k-h
On Wed, Aug 08, 2018 at 08:58:01AM +0800, Jin, Yao wrote:
On 8/7/2018 9:09 PM, Greg KH wrote:
On Mon, Aug 06, 2018 at 08:46:32AM +0800, Jin, Yao wrote:
On 7/19/2018 1:39 AM, Greg KH wrote:
On Wed, Jul 18, 2018 at 10:09:44AM -0700, Andi Kleen wrote:
On Wed, Jul 18, 2018 at 11:29:50AM +0200, Greg KH wrote:
On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote: > Hi, > > The stable kernel 4.9.112 has supported Intel uncore feature in perf core. > While it also needs the perf tool supporting to let perf uncore feature > work. > > Following backport patches enables basic perf uncore feature in 4.9.112. > > For example, on skylake desktop,
Why would anyone care about this on a "desktop" for 4.9? No one should be using 4.9.y on a desktop anymore, it's over 2 years old, why would they expect any "new" hardware support to work for them? Why can't they
It's actually not new hardware support: Skylake is fairly old hardware at this point.
So is 4.9. I don't understand your point. The hardware is obviously newer than 4.9 was, otherwise the support for it would already be in there, right?
just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 year old kernel.
Heck, servers shouldn't either, but that's a totally different rant.
These chips are not only used in desktops but also in servers.
This was asked for with regards to desktops, so now I'm confused. Exactly who/what is going to be needing/wanting/using these changes?
However, for hardware that is newer than the base kernel version release, I have no sympathy. Just use a newer kernel, right?
We have customers which are on old kernels with new hardware.
That's obviously not a wise thing to do for lots of good reasons. This exact example being a huge one (i.e. you can't go back in time and add support for hardware that was not out yet.)
The backports happen either way. This is just an attempt to do it in a coordinated fashion.
There was no coordination here, just a list of git commit ids. Which is great, and all that is really needed, but I'm confused as to who is trying to coordinate with who?
What distro relies on a 4.9 kernel for brand new hardware that does not already support a newer kernel release for such hardware?
None afaik, but there is a lot of Linux use beyond distros.
So no distro uses this, which makes me really wonder who would be the user of these backports. And for how long? Why are these people not moving to 4.14 already given that the published date for 4.9 end-of-life is getting very close. Are you expecting to be rescued by Google again?
Hi Greg,
We do see 4.9 is now used by Alibaba.
Ali kernel is opensourced at https://github.com/alibaba/alikernel
Ok, does this user require these patches? Do they have them in their kernel already? Do they need me to add them before they can use the hardware they already have? I don't understand the connection here...
Hi Greg,
Ali needs the uncore patches and they have backported to their tree. So for adding uncore patches to stable tree, just neutral for them.
I wish to show that 4.9 is being used by some customers.
And why did no one answer all of my questions from my first email?
Sorry about that. I just answer part of questions, for example, "The patchset supports the server like Skylake, and it also supports some old servers, for example, Broadwell and Haswell, .....". I want to represent that it's not only for new hardware like SKL but also for some old hardware which may run with 4.9.
But for other questions, such as, who uses 4.9 in desktop, what distros need 4.9. I'm sorry I don't really know the answers so I don't reply. Sorry about that.
I asked for the diffstat :(
On 8/8/2018 2:40 PM, Greg KH wrote:
On Wed, Aug 08, 2018 at 08:58:01AM +0800, Jin, Yao wrote:
On 8/7/2018 9:09 PM, Greg KH wrote:
On Mon, Aug 06, 2018 at 08:46:32AM +0800, Jin, Yao wrote:
On 7/19/2018 1:39 AM, Greg KH wrote:
On Wed, Jul 18, 2018 at 10:09:44AM -0700, Andi Kleen wrote:
On Wed, Jul 18, 2018 at 11:29:50AM +0200, Greg KH wrote: > On Wed, Jul 18, 2018 at 08:41:28AM +0800, Jin, Yao wrote: >> Hi, >> >> The stable kernel 4.9.112 has supported Intel uncore feature in perf core. >> While it also needs the perf tool supporting to let perf uncore feature >> work. >> >> Following backport patches enables basic perf uncore feature in 4.9.112. >> >> For example, on skylake desktop, > > Why would anyone care about this on a "desktop" for 4.9? No one should > be using 4.9.y on a desktop anymore, it's over 2 years old, why would > they expect any "new" hardware support to work for them? Why can't they
It's actually not new hardware support: Skylake is fairly old hardware at this point.
So is 4.9. I don't understand your point. The hardware is obviously newer than 4.9 was, otherwise the support for it would already be in there, right?
> just use 4.14.y or better yet. 4.17.y? Desktops should NOT be using a 2 > year old kernel. > > Heck, servers shouldn't either, but that's a totally different rant.
These chips are not only used in desktops but also in servers.
This was asked for with regards to desktops, so now I'm confused. Exactly who/what is going to be needing/wanting/using these changes?
> However, for hardware that is newer than the base kernel version > release, I have no sympathy. Just use a newer kernel, right?
We have customers which are on old kernels with new hardware.
That's obviously not a wise thing to do for lots of good reasons. This exact example being a huge one (i.e. you can't go back in time and add support for hardware that was not out yet.)
The backports happen either way. This is just an attempt to do it in a coordinated fashion.
There was no coordination here, just a list of git commit ids. Which is great, and all that is really needed, but I'm confused as to who is trying to coordinate with who?
> What distro relies on a 4.9 kernel for brand new hardware that does not > already support a newer kernel release for such hardware?
None afaik, but there is a lot of Linux use beyond distros.
So no distro uses this, which makes me really wonder who would be the user of these backports. And for how long? Why are these people not moving to 4.14 already given that the published date for 4.9 end-of-life is getting very close. Are you expecting to be rescued by Google again?
Hi Greg,
We do see 4.9 is now used by Alibaba.
Ali kernel is opensourced at https://github.com/alibaba/alikernel
Ok, does this user require these patches? Do they have them in their kernel already? Do they need me to add them before they can use the hardware they already have? I don't understand the connection here...
Hi Greg,
Ali needs the uncore patches and they have backported to their tree. So for adding uncore patches to stable tree, just neutral for them.
I wish to show that 4.9 is being used by some customers.
And why did no one answer all of my questions from my first email?
Sorry about that. I just answer part of questions, for example, "The patchset supports the server like Skylake, and it also supports some old servers, for example, Broadwell and Haswell, .....". I want to represent that it's not only for new hardware like SKL but also for some old hardware which may run with 4.9.
But for other questions, such as, who uses 4.9 in desktop, what distros need 4.9. I'm sorry I don't really know the answers so I don't reply. Sorry about that.
I asked for the diffstat :(
Oh, my mistake, I missed this question. I'm so sorry. :(
Following is the information I get from git format-patch --cover-letter.
Is this the right diffstat?
Andi Kleen (48): perf vendor events: Add BroadwellDE V5 event file perf vendor events: Add Broadwell V17 event file perf vendor events: Add BroadwellX V10 event file perf vendor events: Add Bonnell V4 event file perf vendor events: Add Goldmont V8 event file perf vendor events: Add Haswell V24 event file perf vendor events: Add HaswellX V17 event file perf vendor events: Add IvyBridge V18 event file perf vendor events: Add IvyTown V19 event file perf vendor events: Add Jaketown V20 event file perf vendor events: Add KnightsLanding V9 event file perf vendor events: Add NehalemEP V2 event file perf vendor events: Add NehalemEX V2 event file perf vendor events: Add Skylake V24 event file perf vendor events: Add Silvermont V13 event file perf vendor events: Add SandyBridge V15 event file perf vendor events: Add WestmereEP-DP V2 event file perf vendor events: Add WestmereEP-SP V2 event file perf vendor events: Add WestmereEX V2 event file perf vendor events intel: Add uncore events for Haswell Server processor perf vendor events intel: Add uncore events for Broadwell Server perf vendor events intel: Add uncore events for IvyBridge Server perf vendor events intel: Add uncore events for Sandy Bridge Server perf vendor events intel: Add uncore events for Xeon Phi (Knights Landing) perf vendor events intel: Add uncore events for Broadwell DE perf vendor events intel: Update Intel uncore JSON event files perf vendor events intel: Add missing UNC_M_DCLOCKTICKS for Broadwell DE uncore perf vendor events intel: Add uncore events for Sandy Bridge client perf vendor events intel: Add uncore events for Ivy Bridge client perf vendor events intel: Add uncore events for Haswell client perf vendor events intel: Add uncore events for Broadwell client perf vendor events intel: Add uncore events for Skylake client perf vendor events: Add core event list for Skylake Server perf vendor events: Add Skylake server uncore event list perf jevents: Parse eventcode as number perf jevents: Add support for parsing uncore json files perf pmu: Support per pmu json aliases perf pmu: Support event aliases for non cpu// pmus perf pmu: Factor out scale conversion code perf list: Add debug support for outputing alias string perf tools: Factor out PMU matching in parser perf pmu: Expand PMU events by prefix match perf pmu: Special case uncore_ prefix perf stat: Factor out callback for collecting event values perf stat: Collapse identically named events perf stat: Handle partially bad results with merging perf vendor events intel: Add uncore_arb JSON support perf vendor events intel: Add missing space in json descriptions
Jiri Olsa (2): perf tools: Move new_term arguments into struct parse_events_term template perf tools: Fail on using multiple bits long terms without value
Kan Liang (5): perf/x86/intel/uncore: Fix Skylake server CHA LLC_LOOKUP event umask perf/x86/intel/uncore: Fix Skylake server PCU PMU event format perf/x86/intel/uncore: Remove invalid Skylake server CHA filter field perf/x86/intel/uncore: Add event constraint for BDX PCU perf vendor events: Add Goldmont Plus V1 event file
Stephane Eranian (3): perf/x86/intel/uncore: Fix Skylake UPI PMU event masks perf/x86/intel/uncore: Fix SKX CHA event extra regs perf/x86/intel/uncore: Fix missing marker for skx_uncore_cha_extra_regs
arch/x86/events/intel/uncore_snbep.c | 59 +- tools/perf/Documentation/perf-stat.txt | 3 + tools/perf/builtin-list.c | 3 + tools/perf/builtin-stat.c | 143 +- tools/perf/pmu-events/arch/x86/bonnell/cache.json | 746 ++++ .../arch/x86/bonnell/floating-point.json | 261 ++ .../perf/pmu-events/arch/x86/bonnell/frontend.json | 83 + tools/perf/pmu-events/arch/x86/bonnell/memory.json | 154 + tools/perf/pmu-events/arch/x86/bonnell/other.json | 450 ++ .../perf/pmu-events/arch/x86/bonnell/pipeline.json | 364 ++ .../arch/x86/bonnell/virtual-memory.json | 124 + .../perf/pmu-events/arch/x86/broadwell/cache.json | 3198 +++++++++++++++ .../arch/x86/broadwell/floating-point.json | 171 + .../pmu-events/arch/x86/broadwell/frontend.json | 286 ++ .../perf/pmu-events/arch/x86/broadwell/memory.json | 2845 +++++++++++++ .../perf/pmu-events/arch/x86/broadwell/other.json | 44 + .../pmu-events/arch/x86/broadwell/pipeline.json | 1417 +++++++ .../perf/pmu-events/arch/x86/broadwell/uncore.json | 278 ++ .../arch/x86/broadwell/virtual-memory.json | 388 ++ .../pmu-events/arch/x86/broadwellde/cache.json | 774 ++++ .../arch/x86/broadwellde/floating-point.json | 171 + .../pmu-events/arch/x86/broadwellde/frontend.json | 286 ++ .../pmu-events/arch/x86/broadwellde/memory.json | 433 ++ .../pmu-events/arch/x86/broadwellde/other.json | 44 + .../pmu-events/arch/x86/broadwellde/pipeline.json | 1417 +++++++ .../arch/x86/broadwellde/uncore-cache.json | 317 ++ .../arch/x86/broadwellde/uncore-memory.json | 86 + .../arch/x86/broadwellde/uncore-power.json | 92 + .../arch/x86/broadwellde/virtual-memory.json | 388 ++ .../perf/pmu-events/arch/x86/broadwellx/cache.json | 942 +++++ .../arch/x86/broadwellx/floating-point.json | 171 + .../pmu-events/arch/x86/broadwellx/frontend.json | 286 ++ .../pmu-events/arch/x86/broadwellx/memory.json | 649 +++ .../perf/pmu-events/arch/x86/broadwellx/other.json | 44 + .../pmu-events/arch/x86/broadwellx/pipeline.json | 1417 +++++++ .../arch/x86/broadwellx/uncore-cache.json | 317 ++ .../arch/x86/broadwellx/uncore-interconnect.json | 28 + .../arch/x86/broadwellx/uncore-memory.json | 86 + .../arch/x86/broadwellx/uncore-power.json | 92 + .../arch/x86/broadwellx/virtual-memory.json | 388 ++ tools/perf/pmu-events/arch/x86/goldmont/cache.json | 1127 +++++ .../pmu-events/arch/x86/goldmont/frontend.json | 52 + .../perf/pmu-events/arch/x86/goldmont/memory.json | 34 + tools/perf/pmu-events/arch/x86/goldmont/other.json | 52 + .../pmu-events/arch/x86/goldmont/pipeline.json | 433 ++ .../arch/x86/goldmont/virtual-memory.json | 75 + .../pmu-events/arch/x86/goldmontplus/cache.json | 1453 +++++++ .../pmu-events/arch/x86/goldmontplus/frontend.json | 62 + .../pmu-events/arch/x86/goldmontplus/memory.json | 38 + .../pmu-events/arch/x86/goldmontplus/other.json | 98 + .../pmu-events/arch/x86/goldmontplus/pipeline.json | 544 +++ .../arch/x86/goldmontplus/virtual-memory.json | 218 + tools/perf/pmu-events/arch/x86/haswell/cache.json | 1041 +++++ .../arch/x86/haswell/floating-point.json | 83 + .../perf/pmu-events/arch/x86/haswell/frontend.json | 294 ++ tools/perf/pmu-events/arch/x86/haswell/memory.json | 655 +++ tools/perf/pmu-events/arch/x86/haswell/other.json | 43 + .../perf/pmu-events/arch/x86/haswell/pipeline.json | 1329 ++++++ tools/perf/pmu-events/arch/x86/haswell/uncore.json | 374 ++ .../arch/x86/haswell/virtual-memory.json | 484 +++ tools/perf/pmu-events/arch/x86/haswellx/cache.json | 1077 +++++ .../arch/x86/haswellx/floating-point.json | 83 + .../pmu-events/arch/x86/haswellx/frontend.json | 294 ++ .../perf/pmu-events/arch/x86/haswellx/memory.json | 739 ++++ tools/perf/pmu-events/arch/x86/haswellx/other.json | 43 + .../pmu-events/arch/x86/haswellx/pipeline.json | 1329 ++++++ .../pmu-events/arch/x86/haswellx/uncore-cache.json | 317 ++ .../arch/x86/haswellx/uncore-interconnect.json | 28 + .../arch/x86/haswellx/uncore-memory.json | 86 + .../pmu-events/arch/x86/haswellx/uncore-power.json | 92 + .../arch/x86/haswellx/virtual-memory.json | 484 +++ .../perf/pmu-events/arch/x86/ivybridge/cache.json | 1123 +++++ .../arch/x86/ivybridge/floating-point.json | 151 + .../pmu-events/arch/x86/ivybridge/frontend.json | 305 ++ .../perf/pmu-events/arch/x86/ivybridge/memory.json | 236 ++ .../perf/pmu-events/arch/x86/ivybridge/other.json | 44 + .../pmu-events/arch/x86/ivybridge/pipeline.json | 1307 ++++++ .../perf/pmu-events/arch/x86/ivybridge/uncore.json | 314 ++ .../arch/x86/ivybridge/virtual-memory.json | 180 + tools/perf/pmu-events/arch/x86/ivytown/cache.json | 1272 ++++++ .../arch/x86/ivytown/floating-point.json | 151 + .../perf/pmu-events/arch/x86/ivytown/frontend.json | 305 ++ tools/perf/pmu-events/arch/x86/ivytown/memory.json | 503 +++ tools/perf/pmu-events/arch/x86/ivytown/other.json | 44 + .../perf/pmu-events/arch/x86/ivytown/pipeline.json | 1307 ++++++ .../pmu-events/arch/x86/ivytown/uncore-cache.json | 322 ++ .../arch/x86/ivytown/uncore-interconnect.json | 48 + .../pmu-events/arch/x86/ivytown/uncore-memory.json | 78 + .../pmu-events/arch/x86/ivytown/uncore-power.json | 274 ++ .../arch/x86/ivytown/virtual-memory.json | 198 + tools/perf/pmu-events/arch/x86/jaketown/cache.json | 1290 ++++++ .../arch/x86/jaketown/floating-point.json | 138 + .../pmu-events/arch/x86/jaketown/frontend.json | 305 ++ .../perf/pmu-events/arch/x86/jaketown/memory.json | 422 ++ tools/perf/pmu-events/arch/x86/jaketown/other.json | 58 + .../pmu-events/arch/x86/jaketown/pipeline.json | 1220 ++++++ .../pmu-events/arch/x86/jaketown/uncore-cache.json | 210 + .../arch/x86/jaketown/uncore-interconnect.json | 48 + .../arch/x86/jaketown/uncore-memory.json | 82 + .../pmu-events/arch/x86/jaketown/uncore-power.json | 273 ++ .../arch/x86/jaketown/virtual-memory.json | 149 + .../pmu-events/arch/x86/knightslanding/cache.json | 2305 +++++++++++ .../arch/x86/knightslanding/frontend.json | 34 + .../pmu-events/arch/x86/knightslanding/memory.json | 1110 +++++ .../arch/x86/knightslanding/pipeline.json | 435 ++ .../arch/x86/knightslanding/uncore-memory.json | 42 + .../arch/x86/knightslanding/virtual-memory.json | 65 + tools/perf/pmu-events/arch/x86/mapfile.csv | 37 + .../perf/pmu-events/arch/x86/nehalemep/cache.json | 3229 +++++++++++++++ .../arch/x86/nehalemep/floating-point.json | 229 ++ .../pmu-events/arch/x86/nehalemep/frontend.json | 26 + .../perf/pmu-events/arch/x86/nehalemep/memory.json | 739 ++++ .../perf/pmu-events/arch/x86/nehalemep/other.json | 210 + .../pmu-events/arch/x86/nehalemep/pipeline.json | 881 ++++ .../arch/x86/nehalemep/virtual-memory.json | 109 + .../perf/pmu-events/arch/x86/nehalemex/cache.json | 3184 +++++++++++++++ .../arch/x86/nehalemex/floating-point.json | 229 ++ .../pmu-events/arch/x86/nehalemex/frontend.json | 26 + .../pmu-events/arch/x86/nehalemex/frontend.json | 26 + .../perf/pmu-events/arch/x86/nehalemex/memory.json | 739 ++++ .../perf/pmu-events/arch/x86/nehalemex/other.json | 210 + .../pmu-events/arch/x86/nehalemex/pipeline.json | 881 ++++ .../arch/x86/nehalemex/virtual-memory.json | 109 + .../pmu-events/arch/x86/sandybridge/cache.json | 1879 +++++++++ .../arch/x86/sandybridge/floating-point.json | 138 + .../pmu-events/arch/x86/sandybridge/frontend.json | 305 ++ .../pmu-events/arch/x86/sandybridge/memory.json | 445 ++ .../pmu-events/arch/x86/sandybridge/other.json | 58 + .../pmu-events/arch/x86/sandybridge/pipeline.json | 1220 ++++++ .../pmu-events/arch/x86/sandybridge/uncore.json | 314 ++ .../arch/x86/sandybridge/virtual-memory.json | 149 + .../perf/pmu-events/arch/x86/silvermont/cache.json | 811 ++++ .../pmu-events/arch/x86/silvermont/frontend.json | 47 + .../pmu-events/arch/x86/silvermont/memory.json | 11 + .../pmu-events/arch/x86/silvermont/pipeline.json | 359 ++ .../arch/x86/silvermont/virtual-memory.json | 69 + tools/perf/pmu-events/arch/x86/skylake/cache.json | 4299 ++++++++++++++++++++ .../arch/x86/skylake/floating-point.json | 68 + .../perf/pmu-events/arch/x86/skylake/frontend.json | 472 +++ tools/perf/pmu-events/arch/x86/skylake/memory.json | 2309 +++++++++++ tools/perf/pmu-events/arch/x86/skylake/other.json | 12 + .../perf/pmu-events/arch/x86/skylake/pipeline.json | 939 +++++ tools/perf/pmu-events/arch/x86/skylake/uncore.json | 254 ++ .../arch/x86/skylake/virtual-memory.json | 272 ++ tools/perf/pmu-events/arch/x86/skylakex/cache.json | 1672 ++++++++ .../arch/x86/skylakex/floating-point.json | 88 + .../pmu-events/arch/x86/skylakex/frontend.json | 482 +++ .../perf/pmu-events/arch/x86/skylakex/memory.json | 1396 +++++++ tools/perf/pmu-events/arch/x86/skylakex/other.json | 72 + .../pmu-events/arch/x86/skylakex/pipeline.json | 950 +++++ .../arch/x86/skylakex/uncore-memory.json | 172 + .../pmu-events/arch/x86/skylakex/uncore-other.json | 1156 ++++++ .../arch/x86/skylakex/virtual-memory.json | 284 ++ .../pmu-events/arch/x86/westmereep-dp/cache.json | 2817 +++++++++++++ .../arch/x86/westmereep-dp/floating-point.json | 229 ++ .../arch/x86/westmereep-dp/frontend.json | 26 + .../pmu-events/arch/x86/westmereep-dp/memory.json | 758 ++++ .../pmu-events/arch/x86/westmereep-dp/other.json | 287 ++ .../arch/x86/westmereep-dp/pipeline.json | 899 ++++ .../arch/x86/westmereep-dp/virtual-memory.json | 173 + .../pmu-events/arch/x86/westmereep-sp/cache.json | 3233 +++++++++++++++ .../arch/x86/westmereep-sp/floating-point.json | 229 ++ .../arch/x86/westmereep-sp/frontend.json | 26 + .../pmu-events/arch/x86/westmereep-sp/memory.json | 739 ++++ .../pmu-events/arch/x86/westmereep-sp/other.json | 287 ++ .../arch/x86/westmereep-sp/pipeline.json | 899 ++++ .../arch/x86/westmereep-sp/virtual-memory.json | 149 + tools/perf/pmu-events/jevents.c | 86 +- tools/perf/pmu-events/jevents.h | 4 +- tools/perf/pmu-events/pmu-events.h | 3 + tools/perf/util/evsel.h | 1 + tools/perf/util/parse-events.c | 188 +- tools/perf/util/parse-events.h | 10 + tools/perf/util/parse-events.y | 68 +- tools/perf/util/pmu.c | 122 +- tools/perf/util/pmu.h | 1 + 182 files changed, 97061 insertions(+), 159 deletions(-) create mode 100644 tools/perf/pmu-events/arch/x86/bonnell/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/bonnell/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/bonnell/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/bonnell/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/bonnell/other.json create mode 100644 tools/perf/pmu-events/arch/x86/bonnell/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/bonnell/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/other.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/uncore.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwell/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/other.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/uncore-cache.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/uncore-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/uncore-power.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellde/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/other.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/uncore-cache.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/uncore-interconnect.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/uncore-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/uncore-power.json create mode 100644 tools/perf/pmu-events/arch/x86/broadwellx/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmont/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmont/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmont/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmont/other.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmont/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmont/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmontplus/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmontplus/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmontplus/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmontplus/other.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmontplus/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/goldmontplus/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/haswell/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/haswell/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/haswell/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/haswell/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/haswell/other.json create mode 100644 tools/perf/pmu-events/arch/x86/haswell/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/haswell/uncore.json create mode 100644 tools/perf/pmu-events/arch/x86/haswell/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/other.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/uncore-cache.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/uncore-interconnect.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/uncore-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/uncore-power.json create mode 100644 tools/perf/pmu-events/arch/x86/haswellx/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/other.json create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/uncore.json create mode 100644 tools/perf/pmu-events/arch/x86/ivybridge/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/other.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/uncore-cache.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/uncore-interconnect.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/uncore-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json create mode 100644 tools/perf/pmu-events/arch/x86/ivytown/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/other.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/uncore-cache.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/uncore-interconnect.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/uncore-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/uncore-power.json create mode 100644 tools/perf/pmu-events/arch/x86/jaketown/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/knightslanding/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/knightslanding/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/knightslanding/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/knightslanding/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/knightslanding/uncore-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/knightslanding/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/mapfile.csv create mode 100644 tools/perf/pmu-events/arch/x86/nehalemep/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemep/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemep/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemep/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemep/other.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemep/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemep/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemex/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemex/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemex/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemex/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemex/other.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemex/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/nehalemex/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/other.json create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/uncore.json create mode 100644 tools/perf/pmu-events/arch/x86/sandybridge/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/silvermont/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/silvermont/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/silvermont/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/silvermont/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/silvermont/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/skylake/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/skylake/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/skylake/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/skylake/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/skylake/other.json create mode 100644 tools/perf/pmu-events/arch/x86/skylake/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/skylake/uncore.json create mode 100644 tools/perf/pmu-events/arch/x86/skylake/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/other.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/uncore-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/uncore-other.json create mode 100644 tools/perf/pmu-events/arch/x86/skylakex/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-dp/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-dp/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-dp/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-dp/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-dp/other.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-dp/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-dp/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-sp/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-sp/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-sp/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-sp/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-sp/other.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-sp/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereep-sp/virtual-memory.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereex/cache.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereex/floating-point.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereex/frontend.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereex/memory.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereex/other.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereex/pipeline.json create mode 100644 tools/perf/pmu-events/arch/x86/westmereex/virtual-memory.json
Thanks Jin Yao
On Wed, Aug 08, 2018 at 03:37:54PM +0800, Jin, Yao wrote:
182 files changed, 97061 insertions(+), 159 deletions(-)
Look at that, 97 thousand lines added :(
Yes, almost everything here is in tools/perf/ which leads me to ask why can't you just run a newer kernel's perf on 4.9 and have all of this support? Why do you need these in the stable 4.9 release in order for this to work properly?
And as you can see here, that's really way too big for a stable kernel release, how can you justify it based on the stable kernel rules?
thanks,
greg k-h
On 8/8/2018 4:40 PM, Greg KH wrote:
On Wed, Aug 08, 2018 at 03:37:54PM +0800, Jin, Yao wrote:
182 files changed, 97061 insertions(+), 159 deletions(-)
Look at that, 97 thousand lines added :(
Yes, almost everything here is in tools/perf/ which leads me to ask why can't you just run a newer kernel's perf on 4.9 and have all of this support? Why do you need these in the stable 4.9 release in order for this to work properly?
And as you can see here, that's really way too big for a stable kernel release, how can you justify it based on the stable kernel rules?
thanks,
greg k-h
Yes, I agree, too much code here. :(
And we can use 4.12+ perf tool in 4.9 kernel for using uncore though user may mix the source trees for this. But anyway, this is a solution.
Thanks Jin Yao
On Thu, Aug 09, 2018 at 01:59:09PM +0800, Jin, Yao wrote:
On 8/8/2018 4:40 PM, Greg KH wrote:
On Wed, Aug 08, 2018 at 03:37:54PM +0800, Jin, Yao wrote:
182 files changed, 97061 insertions(+), 159 deletions(-)
Look at that, 97 thousand lines added :(
Yes, almost everything here is in tools/perf/ which leads me to ask why can't you just run a newer kernel's perf on 4.9 and have all of this support? Why do you need these in the stable 4.9 release in order for this to work properly?
And as you can see here, that's really way too big for a stable kernel release, how can you justify it based on the stable kernel rules?
thanks,
greg k-h
Yes, I agree, too much code here. :(
And we can use 4.12+ perf tool in 4.9 kernel for using uncore though user may mix the source trees for this. But anyway, this is a solution.
What do you mean "mix the source trees"?
On 8/9/2018 3:47 PM, Greg KH wrote:
On Thu, Aug 09, 2018 at 01:59:09PM +0800, Jin, Yao wrote:
On 8/8/2018 4:40 PM, Greg KH wrote:
On Wed, Aug 08, 2018 at 03:37:54PM +0800, Jin, Yao wrote:
182 files changed, 97061 insertions(+), 159 deletions(-)
Look at that, 97 thousand lines added :(
Yes, almost everything here is in tools/perf/ which leads me to ask why can't you just run a newer kernel's perf on 4.9 and have all of this support? Why do you need these in the stable 4.9 release in order for this to work properly?
And as you can see here, that's really way too big for a stable kernel release, how can you justify it based on the stable kernel rules?
thanks,
greg k-h
Yes, I agree, too much code here. :(
And we can use 4.12+ perf tool in 4.9 kernel for using uncore though user may mix the source trees for this. But anyway, this is a solution.
What do you mean "mix the source trees"?
I mean, users may need 2 trees. For example, one is 4.14, and the other is 4.9.
They build the perf tool binary in 4.14 and copy it to 4.9 environment.
That's the mix I mean. Sorry, the word may not be very appropriate.
Thanks Jin Yao
linux-stable-mirror@lists.linaro.org
-
Andi Kleen -
Greg KH -
Jin, Yao