On Wed, Nov 07, 2018 at 12:39:31AM +0100, Rafael J. Wysocki wrote: > On Tue, Nov 6, 2018 at 8:51 PM Peter Zijlstra <pet...@infradead.org> wrote: > > > > On Tue, Nov 06, 2018 at 07:19:24PM +0100, Rafael J. Wysocki wrote: > > > On Tue, Nov 6, 2018 at 6:04 PM Peter Zijlstra <pet...@infradead.org> > > > wrote: > > > > > > Instead of this detector; why haven't you used the code from > > > > kernel/irq/timings.c ? > > > > > > Because it doesn't help much AFAICS. > > > > > > Wakeups need not be interrupts in particular > > > > You're alluding to the MWAIT wakeup through the MONITOR address ? > > Yes.
Right, those will not be accounted for and will need something else. > > > and interrupt patterns that show up when the CPU is busy may not be > > > relevant for when it is idle. > > > > I think that is not always true; consider things like the periodic > > interrupt from frame rendering or audio; if there is nothing more going > > on in the system than say playing your favourite tune, it gets the > > 'need more data soon' interrupt from the audio card, wakes up, does a little > > mp3/flac/ogg/whatever decode to fill up the buffer and goes back to > > sleep. Same for video playback I assume, the vsync interrupt for buffer > > flips is fairly predictable. > > > > The interrupt predictor we have in kernel/irq/timings.c should be very > > accurate in predicting those interrupts. > > In the above case the interrupts should produce a detectable pattern > of wakeups anyway. Ah, not so. Suppose you have both the audio and video interrupt going at a steady rate but different rate, then the combined pattern isn't trivial at all. > In general, however, I need to be convinced that interrupts that > didn't wake up the CPU from idle are relevant for next wakeup > prediction. I see that this may be the case, but to what extent is > rather unclear to me and it looks like calling > irq_timings_next_event() would add considerable overhead. How about we add a (debug) knob so that people can play with it for now? If it turns out to be useful, we'll learn.