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