On 11/18/08 11:36, Raj, Ashok wrote: > >> -----Original Message----- >> From: Eric.Saxe at Sun.COM [mailto:Eric.Saxe at Sun.COM] >> Sent: Tuesday, November 18, 2008 11:29 AM >> To: Raj, Ashok >> Cc: Liu, Jiang; Bill.Holler at Sun.COM; Randall Fishel; tesla-dev at >> opensolaris.org >> Subject: Re: [tesla-dev] Request for comment for PSARC onapager about CPU >> idle nofication interface >> >> Raj, Ashok wrote: >> >>> On same lines as predicted-max-idle (possibly from tickless idle subsystem) >>> being passed to >>> >> callbacks, >> >>> Would it be good to tell some measure of outstanding work to the callbacks? >>> That could give some >>> >> indication on intr, and also get the last time we went to idle how long did >> we stay in idle be useful >> measure to pass around? >> >> Interesting, these are the sorts of statistics that the C-state policy >> code will take into consideration when deciding which C-state to >> request. It probably makes sense to expose these via interfaces that >> would be available to all the idle callbacks (not just C-states)? >> > > We use this today in our FBDIMM idle handler to make sure we don't go to > sleep when its not necessary to ensure that no perf degradation happens > during normal busy workloads. Only thing is that the prediction is not > exposed outside FIPE driver, I thought if the predictor is outside could > lighten the code in FIPE :-)
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. Regards, Bill
