* perf: Support uncore in 4.9.112
@ 2018-07-18 0:41 Jin, Yao
2018-07-18 9:29 ` Greg KH
0 siblings, 1 reply; 14+ messages in thread
From: Jin, Yao @ 2018-07-18 0:41 UTC (permalink / raw)
To: stable; +Cc: Jin, Yao, Liang, Kan, Andi Kleen
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-07-18 0:41 perf: Support uncore in 4.9.112 Jin, Yao
@ 2018-07-18 9:29 ` Greg KH
2018-07-18 17:09 ` Andi Kleen
0 siblings, 1 reply; 14+ messages in thread
From: Greg KH @ 2018-07-18 9:29 UTC (permalink / raw)
To: Jin, Yao; +Cc: stable, Jin, Yao, Liang, Kan, Andi Kleen
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 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
What is the overall diffstat of all of these changes?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-07-18 9:29 ` Greg KH
@ 2018-07-18 17:09 ` Andi Kleen
2018-07-18 17:39 ` Greg KH
0 siblings, 1 reply; 14+ messages in thread
From: Andi Kleen @ 2018-07-18 17:09 UTC (permalink / raw)
To: Greg KH; +Cc: Jin, Yao, stable, Jin, Yao, Liang, Kan
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-07-18 17:09 ` Andi Kleen
@ 2018-07-18 17:39 ` Greg KH
2018-07-19 4:43 ` Jin, Yao
2018-08-06 0:46 ` Jin, Yao
0 siblings, 2 replies; 14+ messages in thread
From: Greg KH @ 2018-07-18 17:39 UTC (permalink / raw)
To: Andi Kleen; +Cc: Jin, Yao, stable, Jin, Yao, Liang, Kan
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-07-18 17:39 ` Greg KH
@ 2018-07-19 4:43 ` Jin, Yao
2018-08-06 0:46 ` Jin, Yao
1 sibling, 0 replies; 14+ messages in thread
From: Jin, Yao @ 2018-07-19 4:43 UTC (permalink / raw)
To: Greg KH, Andi Kleen; +Cc: stable, Jin, Yao, Liang, Kan
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-07-18 17:39 ` Greg KH
2018-07-19 4:43 ` Jin, Yao
@ 2018-08-06 0:46 ` Jin, Yao
2018-08-07 13:09 ` Greg KH
1 sibling, 1 reply; 14+ messages in thread
From: Jin, Yao @ 2018-08-06 0:46 UTC (permalink / raw)
To: Greg KH, Andi Kleen; +Cc: stable, Jin, Yao, Liang, Kan
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-08-06 0:46 ` Jin, Yao
@ 2018-08-07 13:09 ` Greg KH
2018-08-08 0:58 ` Jin, Yao
0 siblings, 1 reply; 14+ messages in thread
From: Greg KH @ 2018-08-07 13:09 UTC (permalink / raw)
To: Jin, Yao; +Cc: Andi Kleen, stable, Jin, Yao, Liang, Kan
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-08-07 13:09 ` Greg KH
@ 2018-08-08 0:58 ` Jin, Yao
2018-08-08 6:40 ` Greg KH
0 siblings, 1 reply; 14+ messages in thread
From: Jin, Yao @ 2018-08-08 0:58 UTC (permalink / raw)
To: Greg KH; +Cc: Andi Kleen, stable, Jin, Yao, Liang, Kan
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-08-08 0:58 ` Jin, Yao
@ 2018-08-08 6:40 ` Greg KH
2018-08-08 7:37 ` Jin, Yao
0 siblings, 1 reply; 14+ messages in thread
From: Greg KH @ 2018-08-08 6:40 UTC (permalink / raw)
To: Jin, Yao; +Cc: Andi Kleen, stable, Jin, Yao, Liang, Kan
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 :(
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-08-08 6:40 ` Greg KH
@ 2018-08-08 7:37 ` Jin, Yao
2018-08-08 8:40 ` Greg KH
0 siblings, 1 reply; 14+ messages in thread
From: Jin, Yao @ 2018-08-08 7:37 UTC (permalink / raw)
To: Greg KH; +Cc: Andi Kleen, stable, Jin, Yao, Liang, Kan
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-08-08 7:37 ` Jin, Yao
@ 2018-08-08 8:40 ` Greg KH
2018-08-09 5:59 ` Jin, Yao
0 siblings, 1 reply; 14+ messages in thread
From: Greg KH @ 2018-08-08 8:40 UTC (permalink / raw)
To: Jin, Yao; +Cc: Andi Kleen, stable, Jin, Yao, Liang, Kan
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-08-08 8:40 ` Greg KH
@ 2018-08-09 5:59 ` Jin, Yao
2018-08-09 7:47 ` Greg KH
0 siblings, 1 reply; 14+ messages in thread
From: Jin, Yao @ 2018-08-09 5:59 UTC (permalink / raw)
To: Greg KH; +Cc: Andi Kleen, stable, Jin, Yao, Liang, Kan
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-08-09 5:59 ` Jin, Yao
@ 2018-08-09 7:47 ` Greg KH
2018-08-09 8:07 ` Jin, Yao
0 siblings, 1 reply; 14+ messages in thread
From: Greg KH @ 2018-08-09 7:47 UTC (permalink / raw)
To: Jin, Yao; +Cc: Andi Kleen, stable, Jin, Yao, Liang, Kan
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"?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: perf: Support uncore in 4.9.112
2018-08-09 7:47 ` Greg KH
@ 2018-08-09 8:07 ` Jin, Yao
0 siblings, 0 replies; 14+ messages in thread
From: Jin, Yao @ 2018-08-09 8:07 UTC (permalink / raw)
To: Greg KH; +Cc: Andi Kleen, stable, Jin, Yao, Liang, Kan
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-08-09 10:30 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-07-18 0:41 perf: Support uncore in 4.9.112 Jin, Yao
2018-07-18 9:29 ` Greg KH
2018-07-18 17:09 ` Andi Kleen
2018-07-18 17:39 ` Greg KH
2018-07-19 4:43 ` Jin, Yao
2018-08-06 0:46 ` Jin, Yao
2018-08-07 13:09 ` Greg KH
2018-08-08 0:58 ` Jin, Yao
2018-08-08 6:40 ` Greg KH
2018-08-08 7:37 ` Jin, Yao
2018-08-08 8:40 ` Greg KH
2018-08-09 5:59 ` Jin, Yao
2018-08-09 7:47 ` Greg KH
2018-08-09 8:07 ` Jin, Yao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).