linux-kernel - Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver

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:	Sat, 6 Dec 2008 16:35:39 +0000
From:	Matthew Garrett <mjg@...hat.com>
To:	Tom Hughes <tom@...pton.nu>
Cc:	Thomas Renninger <trenn@...e.de>,
	Cristiano Prisciandaro <cristiano.p@...net.ch>,
	Dave Jones <davej@...hat.com>, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver

On Fri, Dec 05, 2008 at 11:05:39PM +0000, Tom Hughes wrote:
> Thomas Renninger wrote:
> 
> >The biggest problem I see with these "special" ACPI cpufreq interface is:
> >Can there be Asus/eeepcs which provide these ACPI functions (maybe dummies 
> >on
> >future machines?), but can still be switched via the spec conform and more 
> >efficient acpi-cpufreq driver via PSS tables?
> 
> So should we tie this driver to particular DMI signature(s) then? As far 
> as I know it is only useful for the Eee 900 and possibly the 701 when 
> running later BIOSes.

It appears to be implemented in the 900 and 901 BIOSes as well, so some 
kind of limitation is probably needed. The best approach would probably 
to check whether the CPU has the EST flag. Just do something like:

struct cpuinfo_x86 *cpu = &cpu_data(policy->cpu);

if (cpu->x86_vendor != X86_VENDOR_INTEL || cpu_has(cpu, X86_FEATURE_EST))
	return -ENODEV

at the top of the cpufreq init code. That way you'll refuse to bind on 
anything that implements speedstep and acpi-cpufreq can be used instead.

> Running with wifi and the screen off, and the CPU busy (doing m5sum of 
> /dev/zero) I get 2:37 run time at 900MHz and 3:09 at 630MHz so the 
> increase in run time is about 20% on that test.

My only concern about this is that implementing it via cpufreq means 
that on most distributions you'll end up with ondamend running the CPU. 
This makes sense on systems where the cpu scaling drops the voltage, but 
that isn't the case here as far as I can tell. This may result in some 
workloads now having lower battery lives than they did previously. I'll 
try to do some experimentation next week.

Other than that, this patch looks good. I think it makes sense to 
integrate it into eeepc-laptop.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/