linux-kernel - Re: [PATCH] intel_pstate: track and export frequency residency stats via sysfs.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Sep 2014 16:31:41 -0700
From:	Anup Chenthamarakshan <anupc@...omium.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Dirk Brandewie <dirk.j.brandewie@...el.com>,
	Sameer Nanda <snanda@...omium.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] intel_pstate: track and export frequency residency stats
 via sysfs.

On Tue, Sep 09, 2014 at 11:56:18AM +0530, Viresh Kumar wrote:
> On Tue, Sep 9, 2014 at 11:02 AM, Anup Chenthamarakshan
> <anupc@...omium.org> wrote:
> > I had initially tried reusing cpufreq_stats.c to export stats.
> > Calling cpufreq_stats_update() via the cpufreq notifier added
> > some amount of overhead while switching frequencies. Specifically,
> > looking up the index of the new frequency in freq_table_get_index()
> > is a linear search through all available frequencies (vs a single
> > subtraction with custom stats export). Also, the notifier mechanism
> 
> I don't think just this linear search will make things so bad..

Linear search usually slows down transition to higher P-states because
it has to go through the full list (and the list is longer in intel_pstate
compared to acpi-cpufreq). But, yes, this is probably not a bottleneck.

> 
> > itself added a level of indirection before calling stats_update.
> 
> Probably some other notifier is registered which is taking considerable
> amount of time.. Try checking what all registered with cpufreq-core.

There was no other notifier which was listening to freq transitions events.

> 
> > There is a 5X increase in time taken to complete intel_pstate_set_pstate
> > while using cpufreq_stats compared to having custom stats exported.
> 
> Try calling cpufreq_stat_notifier_trans() directly instead of a notifier
> and lets see if this makes it any better.

Here's a comparison of time taken to run intel_pstate_set_pstate() using
different approaches:
                                  average time for a transition
no stats                                      4.7us
intel_pstate-stats                            5.7us
direct call to cpufreq_stat_notifier_trans    8.1us
cpufreq-notifier-event                       10.6us


I was wrong about the 5x increase (got tripped by calls to
intel_pstate_set_pstate where no change in P-state actually happened)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/