The bug described back in 2004 in the following message still seems to exist:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html
Essentially, it appears that if a process sleeps before it uses up a
complete jiffy then no charge is made to its process accounting table.
This problem still exists in the same manner in kernel:
2.6.15-1.2054_FC5smp #1 SMP Tue Mar 14 16:05:46 EST 2006 i686 i686
i386 GNU/Linux
The linked message above contains the necessary code to easily test
for the problem. It compiles cleanly, just be sure to include -lrt on
the command line.
Cheers,
Tom Burns
Problem also verified to exist on kernel:
2.6.17-5mdv #1 SMP Wed Sep 13 14:28:02 EDT 2006 x86_64 Intel(R)
Core(TM)2 CPU 6400 @ 2.13GHz GNU/Linux
Cheers,
Tom Burns
On 1/30/07, Tom Burns <[email protected]> wrote:
> The bug described back in 2004 in the following message still seems to exist:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html
>
> .. snipped..
On Tue, 30 Jan 2007, Tom Burns wrote:
> The bug described back in 2004 in the following message still seems to exist:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html
>
> Essentially, it appears that if a process sleeps before it uses up a
> complete jiffy then no charge is made to its process accounting table.
That's not a bug, it's a feature. ;-)
More seriously, it's a design decision. The benefit of exactly correct
micro bookkeeping does not seem to warrant the extra cost in terms of cpu
cycles spent in the accounting code.
IIRC there was a patch for that some years ago, if you are interested I
will try to find it. No idea how much work it would be to port it to
current kernels, though.
Tim
Hi Tim.
That would be great if you could find that patch - I can worry about
porting it to the current kernel. We're having an issue where our
device, while routing large amounts of network traffic, reports 0% CPU
utilisation when it cannot be the case, and I think this is the cause.
Cheers,
Tom Burns
On 1/30/07, Tim Schmielau <[email protected]> wrote:
> On Tue, 30 Jan 2007, Tom Burns wrote:
>
> > The bug described back in 2004 in the following message still seems to exist:
> >
> > http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html
> >
> > Essentially, it appears that if a process sleeps before it uses up a
> > complete jiffy then no charge is made to its process accounting table.
>
> That's not a bug, it's a feature. ;-)
>
> More seriously, it's a design decision. The benefit of exactly correct
> micro bookkeeping does not seem to warrant the extra cost in terms of cpu
> cycles spent in the accounting code.
>
> IIRC there was a patch for that some years ago, if you are interested I
> will try to find it. No idea how much work it would be to port it to
> current kernels, though.
>
> Tim
>
On Tuesday 30 January 2007 17:24, you wrote:
> The bug described back in 2004 in the following message still seems to
exist:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html
>
> Essentially, it appears that if a process sleeps before it uses up a
> complete jiffy then no charge is made to its process accounting table.
>
> This problem still exists in the same manner in kernel:
This is a known limitation of tick based accounting used on most
architectures.
It was fixed on s390 and using a cpu timer on every context switch. (IIRC ppc
is now using this infrastructure as well)
see for a http://www.kernel-traffic.org/kernel-traffic/kt20041117_284.html#8
for the first patch in the series.
I dont know if there are plans of using the infrastructure on x86 compatible
platforms. I also dont know it that is actually easy to implement with x86
hardware.
--
Mit freundlichen Gr??en / Best Regards
Christian Borntraeger
Linux Software Engineer zSeries Linux & Virtualization
On Tue, 30 Jan 2007, Tom Burns wrote:
> That would be great if you could find that patch - I can worry about
> porting it to the current kernel. We're having an issue where our
> device, while routing large amounts of network traffic, reports 0% CPU
> utilisation when it cannot be the case, and I think this is the cause.
Here is one patch for CPU cycle accounting: (although I'm not sure that's
really the one I had in mind)
http://lkml.org/lkml/2004/6/23/78
It might also be worth having a look at oprofile:
http://oprofile.sourceforge.net/
If you are on IA64 or PPC rather than i386, ppacc might help you:
http://lkml.org/lkml/2006/1/13/308
http://ppacc.sourceforge.net/about.html
Although I'd guess you are not on PPC or S390 as these already to correct
CPU cycle accounting (IIRC).
Hope that helps,
Tim