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]
Message-ID: <1843018.F0kGJi5K1v@vostro.rjw.lan>
Date:	Sat, 27 Apr 2013 16:35:59 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Artem S. Tashkinov" <t.artem@...os.com>
Cc:	linux-kernel@...r.kernel.org, dirk.j.brandewie@...el.com,
	cpufreq@...r.kernel.org, linux-pm@...r.kernel.org,
	dirk.brandewie@...il.com
Subject: Re: CONFIG_X86_INTEL_PSTATE disables CPU frequency transition stats, many governors and other standard features

On Saturday, April 27, 2013 04:58:53 AM Artem S. Tashkinov wrote:
> Hello,
> 
> Just wanted to let everyone know that CONFIG_X86_INTEL_PSTATE wreaks
> havoc with the CPU frequency subsystem in the Linux kernel.
> 
> With this option enabled:
> 
> 1) All governors except performance and powersave are gone, ondemand
> userspace, conservative
> 
> 2) scaling_cur_freq is gone, thus user space utilities monitoring the CPU
> frequency have stopped working
> 
> 3) CPU frequency transition stats are gone, there's no "stats" directory
> anywhere
> 
> 4) scaling_available_frequencies is gone, so I cannot set the desired constant
> CPU frequency (the userspace governor is not available anyway)
> 
> Is this an intended behavior? I shrivel to think that's the case.
> 
> The bug report is filed here: https://bugzilla.kernel.org/show_bug.cgi?id=57141

intel_pstate is not a usual cpufreq driver and from the cpufreq's perspective
it contains its own governor.  That's the reason why the other scaling governors
aren't available with it.

The sysfs attributes mentioned above are missing simply because they don't make
sense with intel_pstate.

I'm only wondering which user space doesn't work correctly with intel_pstate as
you said in the bug entry above.

If you don't want to use intel_pstate (in which case the ACPI driver will be
used instead), please append intel_pstate=disable to the kernel command line.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ