linux-kernel - cpufreq: cpufreq_driver_lock is quite hot on 512p systems

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>] [day] [month] [year] [list]

Message-ID: <20130130180731.GA9449@gulag1.americas.sgi.com>
Date:	Wed, 30 Jan 2013 12:07:32 -0600
From:	Nathan Zimmer <nzimmer@....com>
To:	cpufreq@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: cpufreq: cpufreq_driver_lock is quite hot on 512p systems


I am noticing the cpufreq_driver_lock is quite hot.
Currently on an idle 512 system perf shows me most of the system time is 
spent on this lock.

-  84.18%  [kernel]                 [k] _raw_spin_lock_irqsave
   - _raw_spin_lock_irqsave
      - 99.97% __cpufreq_cpu_get
           cpufreq_cpu_get
           __cpufreq_driver_getavg
           dbs_check_cpu
           od_dbs_timer
           process_one_work
           worker_thread
           kthread
           ret_from_fork
 
The data this lock protects is used in a read mostly situation.
While exprimenting I found turning the lock to a rwlock fixed the problem.
It seems like this might be amenable to using the RCU.

Any other ideas on how to properly resolve the issue?

Thanks,
Nate

--
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/