http://defect.opensolaris.org/bz/show_bug.cgi?id=6232
Summary: Implement code review feedback for Saurabh Misra
Classification: Development
Product: power-mgmt
Version: unspecified
Platform: Other
OS/Version: Solaris
Status: NEW
Severity: normal
Priority: P3
Component: PAD
AssignedTo: eric.saxe at sun.com
ReportedBy: bill.holler at sun.com
CC: tesla-dev at opensolaris.org
Hi --
My comments are below :-
- When PAD is enabled (event mode), where and how do we adjust P-states
depending upon the CPU consumption/utilization? This should help laptops
operating on battery. OR is it still done by cpu module in poll mode?
usr/src/uts/common/disp/disp.c
- I think extra overhead of 'for loop' (depending upon the group
size) in pg_ev_thread_remain()/pg_ev_thread_swtch() can cause
performance degradation in context switch path. It is also not so
obvious as to why we need these callbacks during swtch().
usr/src/uts/i86pc/io/pcplusmp/apic.c
- apic_timer_stop_count() - can put an assert to check if interrupts
are really disabled or not.
usr/src/uts/common/os/pg.c
usr/src/uts/i86pc/io/mp_platform_common.c
usr/src/uts/common/os/pghw.c
- no comments.
usr/src/uts/i86pc/os/cpupm/cpu_idle.c
- Deep C state and C1 state is represented in mc_haltset. Will it be more
expensive to wakeup arbitrary CPU in cstate_wakeup() when the CPU passed is not
in halted cpuset. We may prefer to wakeup CPUs in C1 state rather than in deep
C state. Line 162-177.
- We can also consider time-stamping CPU idle loop. If a CPU has been in
idle state for long then put the CPU in deep-C state. Starting with mwait first
and then progressing to deep-C sleep state. This way if the CPU were to
awakened soon then we will not go through expensive deep-C sleep state
transition.
- I think we would want to consider the size of the system while waking up
CPUs and/or runq of active CPUs. For instance, on a laptop/desktop system, we
shouldn't end up waking up other CPUs through setbackdq()/setfrontdq() if there
is a sudden burst of workload (callback disp_enq_thread is invoked whenever
there is a thread being enqueued in the run queue). I guess runq balance code
may take care of this but just checking. On large systems it will have
cascading effect but I guess we have to do better in numbers and saving power
is secondary at that point of time.
Thanks,
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
