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]
Date:   Thu, 3 Dec 2020 13:41:41 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     Linux PM <linux-pm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Doug Smythies <dsmythies@...us.net>,
        Giovanni Gherdovich <ggherdovich@...e.com>
Subject: Re: [RFC][PATCH 1/2] cpufreq: Add special-purpose fast-switching
 callback for drivers

On Mon, Nov 30, 2020 at 07:37:01PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> 
> First off, some cpufreq drivers (eg. intel_pstate) can pass hints
> beyond the current target frequency to the hardware and there are no

Everything CPPC, which is quite a bit these days.


> +	/*
> +	 * ->fast_switch() replacement for drivers that use an internal
> +	 * representation of performance levels and can pass hints other than
> +	 * the target performance level to the hardware.
> +	 */
> +	void		(*adjust_perf)(unsigned int cpu, bool busy,
> +				       unsigned long min_perf,
> +				       unsigned long target_perf,
> +				       unsigned long capacity);
>  

I'm not sure @busy makes sense, that's more a hack because @util had a
dip and should remain inside schedutil.


> @@ -454,6 +455,25 @@ static void sugov_update_single(struct u
>  	util = sugov_get_util(sg_cpu);
>  	max = sg_cpu->max;
>  	util = sugov_iowait_apply(sg_cpu, time, util, max);
> +
> +	/*
> +	 * This code runs under rq->lock for the target CPU, so it won't run
> +	 * concurrently on two different CPUs for the same target and it is not
> +	 * necessary to acquire the lock in the fast switch case.
> +	 */
> +	if (sg_policy->direct_fast_switch) {
> +		/*
> +		 * In this case, any optimizations that can be done are up to
> +		 * the driver.
> +		 */
> +		cpufreq_driver_adjust_perf(sg_cpu->cpu,
> +					   sugov_cpu_is_busy(sg_cpu),
> +					   map_util_perf(sg_cpu->bw_dl),
> +					   map_util_perf(util), max);
> +		sg_policy->last_freq_update_time = time;
> +		return;
> +	}

Instead of adding more branches, would it makes sense to simply set a
whole different util_hook in this case?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ