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:	Mon, 30 May 2016 15:43:12 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: Re: [PATCH] cpufreq: stats: Make the stats code non-modular

On Mon, May 30, 2016 at 6:53 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 28-05-16, 15:15, Rafael J. Wysocki wrote:
>> It does, but there's a problem.
>>
>> If fast frequency switching is in use, the stats attributes just sit there
>> full of zeros (because the stats are not updated then) which is confusing.
>>
>> Of course, the ultimate solution here would be to make the stats actually
>> work with fast frequency switching, but that requires some major surgery of
>> the stats code, so for now I'd like to simply make those attributes return
>> nothing if fast frequency switching is enabled for the policy (returning
>> -EBUSY from there, which would have been cleaner, unfortunately breaks
>> powertop).
>
> What's stopping us from doing that? Sorry I don't remember that well :(
>
> I mean, why can't we call cpufreq_stats_record_transition() somehow via that
> code ?

Because it does things that aren't allowed to be done from the
scheduler paths (using the non-raw spinlock in the first place).

It also isn't efficient enough.  For example, the fast switch path in
schedutil for non-shared policies is lockless and it would be a shame
to add a lock to it just for the stats.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ