In section "18) Don't re-invent the kernel macros" in "Linux kernel
coding style":
Recommend reusing macros from headers inside include/linux, instead of
the obsolete include/linux/kernel.h
Change wording
- "The header file contains macros" -> "the header files provide macros"
Some macros are
Dear Maintainers,
This patch targets the "Linux kernel coding style" documentation and
recommend reusing macros inside the include/linux directory instead of
the obsolete header "include/linux/kernel.h".
This addresses the issue 'Irrelevant documentation recommending the use
of "include/linux/ker
On 2024-01-09 03:37, Yueh-Shun Li wrote:
Dear Maintainers,
In this version of patch series, I drop the patch abouth the nameing
conflicts caused by locally-defined macro variants to streamline the
documentation.[1]
This series of patches targets the "Linux kernel coding style"
documentation and
Dear Maintainers,
In this version of patch series, I drop the patch abouth the nameing
conflicts caused by locally-defined macro variants to streamline the
documentation.[1]
This series of patches targets the "Linux kernel coding style"
documentation and recommend reusing macros inside the includ
Yueh-Shun Li writes:
>> So everything we add to our documentation has a cost in terms of reader
>> attention. We ask people to read through a lot of material now, and
>> should only increase that ask for good reason.
>>
>> With that context, I have to wonder whether we really need to tell our
>
Dear Mr. Corbet,
Thank you very much for your feed back.
On 2024-01-09 00:28, Jonathan Corbet wrote:
Yueh-Shun Li writes:
In section "18) Don't re-invent the kernel macros" in "Linux kernel
coding style":
Show how reusing macros from shared headers prevents naming collisions
using "stringif
On Mon, 8 Jan 2024 at 17:35, Dietmar Eggemann wrote:
>
> On 08/01/2024 14:48, Vincent Guittot wrote:
> > 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 doz
On 08/01/2024 14:48, Vincent Guittot wrote:
> 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.
Is this then related to the 'medium pace system
Yueh-Shun Li writes:
> In section "18) Don't re-invent the kernel macros" in "Linux kernel
> coding style":
>
> Show how reusing macros from shared headers prevents naming collisions
> using "stringify", the one of the most widely reinvented macro, as an
> example.
>
> This patch aims to provide
In section "18) Don't re-invent the kernel macros" in "Linux kernel
coding style":
Show how reusing macros from shared headers prevents naming collisions
using "stringify", the one of the most widely reinvented macro, as an
example.
This patch aims to provide a stronger reason to reuse shared mac
In section "18) Don't re-invent the kernel macros" in "Linux kernel
coding style":
Recommend reusing macros from headers inside include/linux, instead of
the obsolete include/linux/kernel.h
Change wording
- "The header file contains macros" -> "the header files provide macros"
Some macros are
Dear Maintainers,
This series of patches targets the "Linux kernel coding style"
documentation and recommend reusing macros inside the include/linux
directory instead of the obsolete header "include/linux/kernel.h".
This addresses the issue 'Irrelevant documentation recommending the use
of "inclu
On Wed, Jan 3, 2024 at 11:27 PM Mukesh Ojha wrote:
>
>
> One more thing, kernel part of minidump, we are calling it APSS Minidump
> has limitation of no of entries so it will be difficult to dump
> non-continuous regions after a certain number of registration ~200. However,
> we do have a solution
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
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
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
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
---
kernel/sched/fair.c | 45 +
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
---
drivers/cpufreq/cpufreq.c | 36 +
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
19 matches
Mail list logo
