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 :-) > Sure. It seems like these statistics could be decomposed from the C-state and FIPE callbacks...but that both could consume them. Perhaps even some of the processing of those statistics (e.g. prediction).
-Eric
