Hi,
The upstream kernel has supported IIO free-running counters on Skylake server. As of Skylake Server, there are a number of free running counters in each IIO Box that collect counts of per-box IO clocks and per-port Input/Output x BW/Utilization.
There are three types of IIO free-running counters on Skylake server:
1. IO CLOCKS counter: a clock of IIO box.
2. BANDWIDTH counters: count inbound(PCIe->CPU)/outbound(CPU->PCIe) bandwidth.
3. UTILIZATION counters: count input/output utilization.
With these IIO free-running counters, we can get good observation for IIO traffic on Skylake server. For example, we can see the IIO inbound bandwidth (PCIe->CPU).
root@skx /sys/devices# perf stat -a -e uncore_iio_free_running_2/bw_in_port0/ ^C Performance counter stats for 'system wide':
153.19 MiB uncore_iio_free_running_2/bw_in_port0/
8.037701069 seconds time elapsed
I propose to backport the patches which support IIO free-running counters to 4.14 stable kernel.
perf/x86/intel/uncore: Introduce customized event_read() for client IMC uncore 2da331465f44f9618abe8837d1a68405d550b66e
perf/x86/intel/uncore: Add new data structures for free running counters 927b2deb067b8b4753fc09c7a42092f43fc0c1f6
perf/x86/intel/uncore: Add infrastructure for free running counters 0e0162dfcd1fbe4c711ee86f24f966c318999603
perf/x86/intel/uncore: Support IIO free-running counters on SKX 0f519f0352e37e7d71bdce5559517c74a35f6e33
perf/x86/intel/uncore: Expose uncore_pmu_event*() functions 5a6c9d94e9ed7410142bc6fcb638a4db1895aa0c
perf/x86/intel/uncore: Clean up client IMC uncore 9aae1780e7e81e54edfb70ba33ead5b0b48be009
Thanks Jin Yao
On Tue, Aug 28, 2018 at 11:11:02AM +0800, Jin, Yao wrote:
Hi,
The upstream kernel has supported IIO free-running counters on Skylake server. As of Skylake Server, there are a number of free running counters in each IIO Box that collect counts of per-box IO clocks and per-port Input/Output x BW/Utilization.
There are three types of IIO free-running counters on Skylake server:
IO CLOCKS counter: a clock of IIO box.
BANDWIDTH counters: count inbound(PCIe->CPU)/outbound(CPU->PCIe)
bandwidth.
- UTILIZATION counters: count input/output utilization.
With these IIO free-running counters, we can get good observation for IIO traffic on Skylake server. For example, we can see the IIO inbound bandwidth (PCIe->CPU).
root@skx /sys/devices# perf stat -a -e uncore_iio_free_running_2/bw_in_port0/ ^C Performance counter stats for 'system wide':
153.19 MiB uncore_iio_free_running_2/bw_in_port0/ 8.037701069 seconds time elapsed
I propose to backport the patches which support IIO free-running counters to 4.14 stable kernel.
perf/x86/intel/uncore: Introduce customized event_read() for client IMC uncore 2da331465f44f9618abe8837d1a68405d550b66e
perf/x86/intel/uncore: Add new data structures for free running counters 927b2deb067b8b4753fc09c7a42092f43fc0c1f6
perf/x86/intel/uncore: Add infrastructure for free running counters 0e0162dfcd1fbe4c711ee86f24f966c318999603
perf/x86/intel/uncore: Support IIO free-running counters on SKX 0f519f0352e37e7d71bdce5559517c74a35f6e33
perf/x86/intel/uncore: Expose uncore_pmu_event*() functions 5a6c9d94e9ed7410142bc6fcb638a4db1895aa0c
perf/x86/intel/uncore: Clean up client IMC uncore 9aae1780e7e81e54edfb70ba33ead5b0b48be009
Where in the stable kernel rules does it say that these types of patches are ok to be backported?
Why not just use a newer kernel release if you want to use these new features? What is preventing these users from using 4.18 or newer?
thanks,
greg k-h
On 8/28/2018 1:17 PM, Greg KH wrote:
On Tue, Aug 28, 2018 at 11:11:02AM +0800, Jin, Yao wrote:
Hi,
The upstream kernel has supported IIO free-running counters on Skylake server. As of Skylake Server, there are a number of free running counters in each IIO Box that collect counts of per-box IO clocks and per-port Input/Output x BW/Utilization.
There are three types of IIO free-running counters on Skylake server:
IO CLOCKS counter: a clock of IIO box.
BANDWIDTH counters: count inbound(PCIe->CPU)/outbound(CPU->PCIe)
bandwidth.
- UTILIZATION counters: count input/output utilization.
With these IIO free-running counters, we can get good observation for IIO traffic on Skylake server. For example, we can see the IIO inbound bandwidth (PCIe->CPU).
root@skx /sys/devices# perf stat -a -e uncore_iio_free_running_2/bw_in_port0/ ^C Performance counter stats for 'system wide':
153.19 MiB uncore_iio_free_running_2/bw_in_port0/ 8.037701069 seconds time elapsed
I propose to backport the patches which support IIO free-running counters to 4.14 stable kernel.
perf/x86/intel/uncore: Introduce customized event_read() for client IMC uncore 2da331465f44f9618abe8837d1a68405d550b66e
perf/x86/intel/uncore: Add new data structures for free running counters 927b2deb067b8b4753fc09c7a42092f43fc0c1f6
perf/x86/intel/uncore: Add infrastructure for free running counters 0e0162dfcd1fbe4c711ee86f24f966c318999603
perf/x86/intel/uncore: Support IIO free-running counters on SKX 0f519f0352e37e7d71bdce5559517c74a35f6e33
perf/x86/intel/uncore: Expose uncore_pmu_event*() functions 5a6c9d94e9ed7410142bc6fcb638a4db1895aa0c
perf/x86/intel/uncore: Clean up client IMC uncore 9aae1780e7e81e54edfb70ba33ead5b0b48be009
Where in the stable kernel rules does it say that these types of patches are ok to be backported?
Why not just use a newer kernel release if you want to use these new features? What is preventing these users from using 4.18 or newer?
thanks,
greg k-h
Hi Greg,
Yes, the stable kernel doesn't contain one rule that it can accept a new feature. (https://www.kernel.org/doc/html/v4.15/process/stable-kernel rules.html)
While this proposed feature (IIO free-running counters) is useful for server users to observe the data traffic between CPU and IO on Skylake server. For server customers, we know they prefer to use stable kernels.
The customers may maintain their own branches with the patches. But from my personal opinion, it would be better if the official stable kernel can support that. That's just my proposal. :)
Thanks Jin Yao
On Tue, Aug 28, 2018 at 02:23:38PM +0800, Jin, Yao wrote:
On 8/28/2018 1:17 PM, Greg KH wrote:
On Tue, Aug 28, 2018 at 11:11:02AM +0800, Jin, Yao wrote:
Hi,
The upstream kernel has supported IIO free-running counters on Skylake server. As of Skylake Server, there are a number of free running counters in each IIO Box that collect counts of per-box IO clocks and per-port Input/Output x BW/Utilization.
There are three types of IIO free-running counters on Skylake server:
IO CLOCKS counter: a clock of IIO box.
BANDWIDTH counters: count inbound(PCIe->CPU)/outbound(CPU->PCIe)
bandwidth.
- UTILIZATION counters: count input/output utilization.
With these IIO free-running counters, we can get good observation for IIO traffic on Skylake server. For example, we can see the IIO inbound bandwidth (PCIe->CPU).
root@skx /sys/devices# perf stat -a -e uncore_iio_free_running_2/bw_in_port0/ ^C Performance counter stats for 'system wide':
153.19 MiB uncore_iio_free_running_2/bw_in_port0/ 8.037701069 seconds time elapsed
I propose to backport the patches which support IIO free-running counters to 4.14 stable kernel.
perf/x86/intel/uncore: Introduce customized event_read() for client IMC uncore 2da331465f44f9618abe8837d1a68405d550b66e
perf/x86/intel/uncore: Add new data structures for free running counters 927b2deb067b8b4753fc09c7a42092f43fc0c1f6
perf/x86/intel/uncore: Add infrastructure for free running counters 0e0162dfcd1fbe4c711ee86f24f966c318999603
perf/x86/intel/uncore: Support IIO free-running counters on SKX 0f519f0352e37e7d71bdce5559517c74a35f6e33
perf/x86/intel/uncore: Expose uncore_pmu_event*() functions 5a6c9d94e9ed7410142bc6fcb638a4db1895aa0c
perf/x86/intel/uncore: Clean up client IMC uncore 9aae1780e7e81e54edfb70ba33ead5b0b48be009
Where in the stable kernel rules does it say that these types of patches are ok to be backported?
Why not just use a newer kernel release if you want to use these new features? What is preventing these users from using 4.18 or newer?
thanks,
greg k-h
Hi Greg,
Yes, the stable kernel doesn't contain one rule that it can accept a new feature. (https://www.kernel.org/doc/html/v4.15/process/stable-kernel rules.html)
Which means it is not allowed, correct?
While this proposed feature (IIO free-running counters) is useful for server users to observe the data traffic between CPU and IO on Skylake server. For server customers, we know they prefer to use stable kernels.
Everyone wants to backport "just one new thing" to make their lives easier. That's not how the stable kernels work. If you want something like that, go run an "enterprise" kernel from RHEL or SLES, they will be glad to charge you for the additional support costs that something like that causes. I am not in the business of doing that, you know better.
The customers may maintain their own branches with the patches. But from my personal opinion, it would be better if the official stable kernel can support that. That's just my proposal. :)
What is "unstable" about 4.18 that they can not use that?
thanks,
greg k-h
On 8/28/2018 8:43 PM, Greg KH wrote:
On Tue, Aug 28, 2018 at 02:23:38PM +0800, Jin, Yao wrote:
On 8/28/2018 1:17 PM, Greg KH wrote:
On Tue, Aug 28, 2018 at 11:11:02AM +0800, Jin, Yao wrote:
Hi,
The upstream kernel has supported IIO free-running counters on Skylake server. As of Skylake Server, there are a number of free running counters in each IIO Box that collect counts of per-box IO clocks and per-port Input/Output x BW/Utilization.
There are three types of IIO free-running counters on Skylake server:
IO CLOCKS counter: a clock of IIO box.
BANDWIDTH counters: count inbound(PCIe->CPU)/outbound(CPU->PCIe)
bandwidth.
- UTILIZATION counters: count input/output utilization.
With these IIO free-running counters, we can get good observation for IIO traffic on Skylake server. For example, we can see the IIO inbound bandwidth (PCIe->CPU).
root@skx /sys/devices# perf stat -a -e uncore_iio_free_running_2/bw_in_port0/ ^C Performance counter stats for 'system wide':
153.19 MiB uncore_iio_free_running_2/bw_in_port0/ 8.037701069 seconds time elapsed
I propose to backport the patches which support IIO free-running counters to 4.14 stable kernel.
perf/x86/intel/uncore: Introduce customized event_read() for client IMC uncore 2da331465f44f9618abe8837d1a68405d550b66e
perf/x86/intel/uncore: Add new data structures for free running counters 927b2deb067b8b4753fc09c7a42092f43fc0c1f6
perf/x86/intel/uncore: Add infrastructure for free running counters 0e0162dfcd1fbe4c711ee86f24f966c318999603
perf/x86/intel/uncore: Support IIO free-running counters on SKX 0f519f0352e37e7d71bdce5559517c74a35f6e33
perf/x86/intel/uncore: Expose uncore_pmu_event*() functions 5a6c9d94e9ed7410142bc6fcb638a4db1895aa0c
perf/x86/intel/uncore: Clean up client IMC uncore 9aae1780e7e81e54edfb70ba33ead5b0b48be009
Where in the stable kernel rules does it say that these types of patches are ok to be backported?
Why not just use a newer kernel release if you want to use these new features? What is preventing these users from using 4.18 or newer?
thanks,
greg k-h
Hi Greg,
Yes, the stable kernel doesn't contain one rule that it can accept a new feature. (https://www.kernel.org/doc/html/v4.15/process/stable-kernel rules.html)
Which means it is not allowed, correct?
Oh, yes, no rule means not allowed. So the stable kernel basically rejects the new feature.
While this proposed feature (IIO free-running counters) is useful for server users to observe the data traffic between CPU and IO on Skylake server. For server customers, we know they prefer to use stable kernels.
Everyone wants to backport "just one new thing" to make their lives easier. That's not how the stable kernels work. If you want something like that, go run an "enterprise" kernel from RHEL or SLES, they will be glad to charge you for the additional support costs that something like that causes. I am not in the business of doing that, you know better.
OK, that makes sense.
The customers may maintain their own branches with the patches. But from my personal opinion, it would be better if the official stable kernel can support that. That's just my proposal. :)
What is "unstable" about 4.18 that they can not use that?
Sorry, I mean the LTS kernel (4.4/4.9/4.14). 4.18 is fine, but people might prefer to build his branch on LTS kernel. That would be understandable.
Thanks Jin Yao
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org