kernel.git/drivers/cpufreq/cpufreq_stats.c, branch linux-4.5.y

cpufreq: stats: drop unnecessary locking

2015-01-23T22:06:45Z

There is no possibility of any race on updating last_index, trans_table or total_trans as these are updated only by cpufreq_stat_notifier_trans() which will be called sequentially. The only place where locking is still relevant is: cpufreq_stats_update(), which updates time_in_state and last_time. This can be called by two thread in parallel, that may result in races. The two threads being: - sysfs read of time_in_state - and frequency transition that calls cpufreq_stat_notifier_trans(). Remove locking from the first case mentioned above. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: don't update stats on false notifiers

2015-01-23T22:06:45Z

We need to call cpufreq_stats_update() to update 'time_in_state' for the last frequency. This is achieved by calling it from cpufreq_stat_notifier_trans(), which is called after frequency transition. But if we detect that the cpu's frequency haven't really changed and its a false POSTCHANGE notification, we don't really need to update time_in_state. It wouldn't cause any harm in calling cpufreq_stats_update() but we can avoid calling it here and call it when the frequency really changes. The result will be the same but more efficient. Reviewed-by: Prarit Bhargava Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: don't update stats from show_trans_table()

2015-01-23T22:06:45Z

cpufreq_stats_update() updates time_in_state and nothing else. It should ideally be updated only in two cases: - User requested for the current value of time_in_state. - We have switched states and so need to update time for the last state. Currently, we are also doing this while user asks for the transition table of frequencies. It wouldn't do any harm, but no good as well. Its useless here. Remove it. Reviewed-by: Prarit Bhargava Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: time_in_state can't be NULL in cpufreq_stats_update()

2015-01-23T22:06:44Z

'time_in_state' can't be NULL if 'stats' is valid. These are allocated together and only if time_in_state is allocated successfully, we update policy->stats. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: create sysfs group once we are ready

2015-01-23T22:06:44Z

Userspace is free to read value of any file from cpufreq/stats directory once they are created. __cpufreq_stats_create_table() is creating the sysfs files first and then allocating resources for them. Though it would be quite difficult to trigger the racy situation here, but for the sake of keeping sensible code lets create sysfs entries only after we are ready to go. This also does some makeup to the routine to make it look better. Reviewed-by: Prarit Bhargava Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: drop 'cpu' field of struct cpufreq_stats

2015-01-23T22:06:44Z

'cpu' field of struct cpufreq_stats isn't used anymore and so can be dropped. This change makes cpufreq_stats_update_policy_cpu() empty and so that is removed as well. Reviewed-by: Prarit Bhargava Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: rename 'struct cpufreq_stats' objects as 'stats'

2015-01-23T22:06:44Z

Currently we name objects of 'struct cpufreq_stats' as 'stat' and 'stats'. Use 'stats' to make it consistent. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: get rid of per-cpu cpufreq_stats_table

2015-01-23T22:06:44Z

All CPUs sharing a cpufreq policy share stats too. For this reason, add a stats pointer to struct cpufreq_policy and drop per-CPU variable cpufreq_stats_table used for accessing cpufreq stats so as to reduce code complexity. Reviewed-by: Prarit Bhargava Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: pass 'stat' to cpufreq_stats_update()

2015-01-23T22:06:44Z

It is better to pass a struct cpufreq_stats pointer to cpufreq_stats_update() instead of a CPU number, because that's all it needs. Even if we pass a cpu number to cpufreq_stats_update(), it reads the per-cpu variable to get 'stats' out of it. So we are doing these operations unnecessarily: - First getting the cpu number to pass to cpufreq_stats_update(), stat->cpu. - And then getting stats from the cpu, per_cpu(cpufreq_stats_table, cpu). Reviewed-by: Prarit Bhargava Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: don't check for freq table while freeing stats

2015-01-23T22:06:43Z

While we allocate stats, we do need to check if freq-table is present or not as we need to use it then. But while freeing stats, all we need to know is if stats holds a valid pointer value. There is no use of testing if cpufreq table is present or not. Don't check it. Reviewed-by: Prarit Bhargava Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki