Re: [PATCH] Documentation/ftrace: Correct wording on trace_options sharing

On 2/20/24 21:00, Dmitry Safonov wrote: [..] > diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst > index 7e7b8ec17934..c79a6bcef3c9 100644 > --- a/Documentation/trace/ftrace.rst > +++ b/Documentation/trace/ftrace.rst > @@ -3603,9 +3603,9 @@ The files in the new directory

[PATCH] Documentation/ftrace: Correct wording on trace_options sharing

reside in, but +trace_printk, printk-msg-only and record-cmd are affecting all instances +and the top level buffer, but this may change in future releases. Notice that none of the function tracer files are there, nor is current_tracer and available_tracers. This is because the buffers

[PATCH v5 5/5] sched/pelt: Remove shift of thermal clock

The optional shift of the clock used by thermal/hw load avg has been introduced to handle case where the signal was not always a high frequency hw signal. Now that cpufreq provides a signal for firmware and SW pressure, we can remove this exception and always keep this PELT signal aligned with othe

[PATCH v5 4/5] sched: Rename arch_update_thermal_pressure into arch_update_hw_pressure

Now that cpufreq provides a pressure value to the scheduler, rename arch_update_thermal_pressure into HW pressure to reflect that it returns a pressure applied by HW (i.e. with a high frequency change) and not always related to thermal mitigation but also generated by max current limitation as an e

[PATCH v5 3/5] thermal/cpufreq: Remove arch_update_thermal_pressure()

arch_update_thermal_pressure() aims to update fast changing signal which should be averaged using PELT filtering before being provided to the scheduler which can't make smart use of fast changing signal. cpufreq now provides the maximum freq_qos pressure on the capacity to the scheduler, which incl

[PATCH v5 2/5] sched: Take cpufreq feedback into account

Aggregate the different pressures applied on the capacity of CPUs and create a new function that returns the actual capacity of the CPU: get_actual_cpu_capacity() Signed-off-by: Vincent Guittot Reviewed-by: Lukasz Luba Reviewed-by: Qais Yousef --- kernel/sched/fair.c | 45 +++

[PATCH v5 1/5] cpufreq: Add a cpufreq pressure feedback for the scheduler

Provide to the scheduler a feedback about the temporary max available capacity. Unlike arch_update_thermal_pressure, this doesn't need to be filtered as the pressure will happen for dozens ms or more. Signed-off-by: Vincent Guittot Acked-by: Rafael J. Wysocki Acked-by: Viresh Kumar Reviewed-by:

[PATCH v5 0/5] Rework system pressure interface to the scheduler

Following the consolidation and cleanup of CPU capacity in [1], this serie reworks how the scheduler gets the pressures on CPUs. We need to take into account all pressures applied by cpufreq on the compute capacity of a CPU for dozens of ms or more and not only cpufreq cooling device or HW mitigiat

Re: [PATCH v5] Documentation: Document the Linux Kernel CVE process

On Tue, Feb 20, 2024 at 11:03:17AM +0100, Vegard Nossum wrote: > > On 17/02/2024 13:55, Greg Kroah-Hartman wrote: > > +A list of all assigned CVEs for the Linux kernel can be found in the > > +archives of the linux-cve mailing list, as seen on > > +https://lore.kernel.org/linux-cve-announce/. To

Re: [PATCH v5] Documentation: Document the Linux Kernel CVE process

On 17/02/2024 13:55, Greg Kroah-Hartman wrote: +A list of all assigned CVEs for the Linux kernel can be found in the +archives of the linux-cve mailing list, as seen on +https://lore.kernel.org/linux-cve-announce/. To get notice of the +assigned CVEs, please `subscribe +