On 10/27/08 23:12, Li, Aubrey wrote: > tesla-dev-bounces at opensolaris.org wrote: > > >> Bill.Holler wrote: >> >> >>> Do we want to change cpu_idle_init to return failure right away >>> when Deep C-States are not supported? cpu_idle_init can check >>> cpu_deep_cstates_supported(). Currently cpudrv queries ACPI for >>> C-State info even when idle_cpu_no_deep_c is set. I think this is >>> leftover from before we had the cpu_deep_idle tunable. >>> >>> >>> Here is a proposal for variable/keyword semantics: >>> >>> idle_cpu_no_deep_c: >>> Disables ACPI query for C-State information. Disables C-states. >>> Kernel will not report valid C-state information in kstat(s). >>> Usage: only used to workaround a bug in ACPI, hardware, or >>> software. >>> >> This sounds good. We can have a chance to boot kernel with buggy BIOS. >> >> >>> cpu_deep_idle: >>> Do not use C-States for performance reasons. >>> Kernel can query ACPI. Kernel will still report available C-State >>> information in various kstat(s). >>> Usage: disable C-States solely for performance reasons. >>> >>> >> Do we see obvious performance difference? From last SPECpower result, >> we only lost 1%~ performance while we still get 3W~ power saving. >> IMHO, this may be implemented by PAD, load balance policy could let >> cpu sleep shorter and not deeper. >> >> Or, is there any another reason to introduce this variable? >>
Some applications may require small scheduling latency. > Sorry for the confusion. I thought you mean we need to dynamically > disable/enable c-state by cpu_deep_idle. we certainly are fine to use > cpu_deep_idle as an parameter of pmconfig. > > Regards, > -Aubrey > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev > The admin can change cpu_deep_idle in power.conf and run pmconfig at any time. We do not expect this setting to be used much. When this tunable is used we expect it to be set to one value and left there. The long term plan is to have multiple power policies the admin can choose. These settings could make changes in the PAD layer. I am lobbying Eric to make the PAD dynamic for long term tuning. :-) Thank you, Bill
