Messages in this thread | | | Date | Thu, 27 Jul 2023 09:59:22 +0200 | From | Peter Zijlstra <> | Subject | Re: Stopping the tick on a fully loaded system |
| |
On Wed, Jul 26, 2023 at 06:14:32PM +0200, Peter Zijlstra wrote: > On Wed, Jul 26, 2023 at 05:53:46PM +0200, Rafael J. Wysocki wrote: > > > > > That means we don't track nearly enough data to reliably tell anything > > > > about disabling the tick or not. We should have at least one bucket > > > > beyond TICK_NSEC for this. > > > > > > Quite likely. > > > > So the reasoning here was that those additional bins would not be > > necessary for idle state selection, but the problem of whether or not > > to stop the tick is kind of separate from the idle state selection > > problem if the target residency values for all of the idle states are > > relatively short. And so it should be addressed separately which > > currently it is not. Admittedly, this is a mistake. > > Right, the C state buckets are enough to pick a state, but not to handle > the tick thing. > > The below hack boots on my ivb-ep with extra (disabled) states. Now let > me go hack up teo to make use of that. > > name residency > > POLL 0 > C1 1 > C1E 80 > C3 156 > C6 300 > TICK 1000 > POST-TICK 2000 >
Ah, so last night (or rather, somewhat realy today) I realized I has the buckets wrong.
We don't have buckets to the left, but buckets to the right, so the above would give:
0: [0,1) 1: [1,80) 2: [80,156) 3: [156,300) 4: [300,1000) 5: [1000,2000) 6: [2000,...)
Which also means I can ditch the whole POST-TICK bucket. Let me get breakfast and try all this again.
| |