lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANDhNCrU3uuA137Udvh+RfC9ELhc7scjR=Oacosbyw+b68AR3Q@mail.gmail.com>
Date: Tue, 12 Nov 2024 20:51:15 -0800
From: John Stultz <jstultz@...gle.com>
To: Qais Yousef <qyousef@...alina.io>
Cc: Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
	Vincent Guittot <vincent.guittot@...aro.org>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Viresh Kumar <viresh.kumar@...aro.org>, Juri Lelli <juri.lelli@...hat.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Dietmar Eggemann <dietmar.eggemann@....com>, linux-pm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 05/16] sched: cpufreq: Remove magic 1.25 headroom from sugov_apply_dvfs_headroom()

On Tue, Aug 20, 2024 at 9:35 AM Qais Yousef <qyousef@...alina.io> wrote:
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 575df3599813..303b0ab227e7 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -187,13 +187,28 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
>   * to run at adequate performance point.
>   *
>   * This function provides enough headroom to provide adequate performance
> - * assuming the CPU continues to be busy.
> + * assuming the CPU continues to be busy. This headroom is based on the
> + * dvfs_update_delay of the cpufreq governor or min(curr.se.slice, TICK_US),
> + * whichever is higher.
>   *
> - * At the moment it is a constant multiplication with 1.25.
> + * XXX: Should we provide headroom when the util is decaying?
>   */
> -static inline unsigned long sugov_apply_dvfs_headroom(unsigned long util)
> +static inline unsigned long sugov_apply_dvfs_headroom(unsigned long util,  int cpu)
>  {
> -       return util + (util >> 2);
> +       struct rq *rq = cpu_rq(cpu);
> +       u64 delay;
> +
> +       /*
> +        * What is the possible worst case scenario for updating util_avg, ctx
> +        * switch or TICK?
> +        */
> +       if (rq->cfs.h_nr_running > 1)
> +               delay = min(rq->curr->se.slice/1000, TICK_USEC);

Nit: this fails to build on 32bit due to the u64 division.

Need something like:
       if (rq->cfs.h_nr_running > 1) {
               u64 slice = rq->curr->se.slice;

               do_div(slice, 1000);
               delay = min(slice, TICK_USEC);
       } else
...

thanks
-john

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ