>-----Original Message----- >From: Bill.Holler at Sun.COM [mailto:Bill.Holler at Sun.COM] >Sent: Tuesday, November 18, 2008 1:14 PM >To: Raj, Ashok; tesla-dev at opensolaris.org >Cc: Eric.Saxe at Sun.COM; Randall Fishel >Subject: Re: [tesla-dev] Request for comment for PSARC onapager about CPU idle >nofication interface > >On 11/18/08 12:30, Raj, Ashok wrote: >> >>> -----Original Message----- >>> From: Eric.Saxe at Sun.COM [mailto:Eric.Saxe at Sun.COM] >>> Sent: Tuesday, November 18, 2008 11:54 AM >>> To: Bill.Holler at Sun.COM >>> Cc: Raj, Ashok; Randall Fishel; tesla-dev at opensolaris.org >>> Subject: Re: [tesla-dev] Request for comment for PSARC onapager about CPU >>> idle nofication interface >>> >>> Bill Holler wrote: >>> >>>> What interface should we use if things like intr rate and previous >>>> idle duration are canlculated in the kernel? Should this be an >>>> argument to the idle callback? Another option is to keep this data >>>> in the per-cpu mach_cpu structure which the callbacks can access. >>>> >>>> >>> It would probably be better provide this through accessor interfaces... >>> rather than having the callbacks have to know about mach_cpu... >>> >> >> >> Much better! > >What data do we want in these accessor interfaces? >This data is available: > 1) max-idle duration via LAPIC Current Count register.
Is this always from LAPIC? What if you enter a deep c-state and you rely on other timer sources? Anyway anticipated max duration of sleep is useful. > 2) last idle duration Probably #2 along with previous anticipated actual? Just to know if we could auto-demote? > 3) possibly a running average idle time > 4) ACPI round trip latency of the current target C-State. > 5) intr rate calculation. > 6) target C-State. Does the target c-state really matter? Or do we need just item #4 above? > >Is there anything else? >Which of this data is useful? > >Bill
