Hi.. On Thu, Sep 11, 2008 at 12:36 AM, Elad Lahav <elad_lahav@xxxxxxxxxxxxxxxxxxxxx> wrote: > In account_system_time(), the current tick is accredited to SoftIRQ time if > softirq_count() is not 0. This value is incremented by __local_bh_disable(), > which is called from __do_softirq(). So far so good. However, > __local_bh_disable() is also called from local_bh_disable(), which is called > by other functions in the kernel. The result is that if a timer interrupt > happens when the kernel is executing in a function that call > local_bh_disable(), the tick is accredited to SoftIRQ time. > Is this a bug, or is the statistics set up this way on purpose (or am I > missing something)? I recheck the fact you found and here's what I thought: yes, the tick will be attributed to softirq, however as we know disabling local bottom halves won't happen too long...so soon after it's enabled again, tick accounting will be back attributed to system time. So I think it's a tough choice, finer check would made the accounting better, however I guess this decision is made to make to coding simpler. Again, by simply taking this rule in heart: disabling bottom halves should be as fast as possible. So that time would be just a tiny fraction of the whole time "stolen" by the real system tick that should be accounted. make sense, people? regards, Mulyadi. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
