Many mfgpt timer interrupts with tickless kernel

[William Cohen]

Jens Axboe wrote:
> On Thu, Mar 22 2007, William Cohen wrote:
>> Hi all,
>>
>> I was trying to make sense of the data that I collected earlier with the 
>> idle1.stp probe. It displayed the percentage of time spent in halted mode, 
>> which the highest I saw on an idle machine was 17 percentage. This seemed 
>> rather low for a machine that was doing nothing, so I took a closer look at 
>> what was going on the idle machine. All this work is based on kernel built 
>> from dilinger's:
>>
>> kernel-2.6.21-20070312.1.olpc.3eca75102a57502.src.rpm
>>
>> I ran an experiment where the machine state idle for 10 seconds with the 
>> systemtap script running. I also compared the number of interrupts before 
>> and after the experiment. There is about 150 interrupts per second from the 
>> mfgpt timer. I thought with the tickless kernel that this would be a lot 
>> lower.
>> Below is the data from the experiment. I tried booting the machine in 
>> runlevel three and got the same results, about 150 interrupts per second. 
>> Why so many timer interrupts for tickless kernel?
> 
> The tickless kernel just _enables_ low number of interrupts per second,
> it'll still wakeup everytime something is scheduled to run. So you
> probably want to look into _why_ th timer interrupts happen so often -
> who is the user of them?
> 
> I see ~70 interrupts/sec here with an idle machine in X, FWIW.
> 


I have an additional usb ethernet dongle and usb flash drive on the machine.
I ran without thoses devices and to see if that changes the results. Running 
without the usb flash had a similar number of interrupts per second.
Removing both usb ethernet and usb flash still same number of interrupts. It is 
also the same number of interrupts when measurements done in runlevel 3.

I put a probe on mfgpt_next_event(). The ones that I did so far collected 
process and pid information when the function was called. The backtraces look 
suspect and in the vast majority of cases the pid was 0. Is this being reset in 
a irq routine?

I need to put a probe at a higher level to see what is run when the timer fires. 
  Is there something that can  print out what is in the clockevents_chain?

-Will