You said the
smallhog process shows 80% CPU time. The remaining 20% of the time on that CPU is accounted to interrupts! Why does smallhog.c show less than 100% CPU usage on my system?
smallhog is doing something very interrupt-intensive. Its specific tactic is clearly defeated by
IRQ_TIME_ACCOUNTING. See below.
I suspect there is still a way to dodge the timer tick :-). You probably need a clever way to predict when the tick will fire. E.g. by looking at
bool "Fine granularity task level IRQ time accounting"
depends on HAVE_IRQ_TIME_ACCOUNTING && !VIRT_CPU_ACCOUNTING_NATIVE
Select this option to enable fine granularity task irq time
accounting. This is done by reading a timestamp on each
transitions between softirq and hardirq state, so there can be a
small performance impact.
If in doubt, say N here.
This feature is enabled in Fedora kernel configurations (see
/boot/config-*). On x86 CPUs, it uses the TSC. The feature can be disabled with a boot-time option,
More accurate accounting methods
As mentioned in the question, PowerPC / S390 have specific code
that can account CPU time on every single context switch. This is called
VIRT_CPU_ACCOUNTING_NATIVE. But your x86 kernel does not have this.
There is a generic equivalent, called
VIRT_CPU_ACCOUNTING_GEN. (GEN is short for "generic"). This feature is built in to your Fedora kernel. But this feature is not activated by default.
You have to read carefully :-).
VIRT_CPU_ACCOUNTING_GEN only becomes active on "full dynticks systems". Although the Fedora kernel configuration includes
NO_HZ_FULL, Fedora does not enabled "full dynticks" by default. Enabling "full dynticks" requires specifying an option at boot time,
nohz_full=, with a list of "adaptive-ticks CPUs". ("At least one non-adaptive-tick CPU must remain online ...")
menu "CPU/Task time and stats accounting"
prompt "Cputime accounting"
default TICK_CPU_ACCOUNTING if !PPC64
default VIRT_CPU_ACCOUNTING_NATIVE if PPC64
# Kind of a stub config for the pure tick based cputime accounting
bool "Simple tick based cputime accounting"
depends on !S390 && !NO_HZ_FULL
This is the basic tick based cputime accounting that maintains
statistics about user, system and idle time spent on per jiffies
If unsure, say Y.
bool "Deterministic task and CPU time accounting"
depends on HAVE_VIRT_CPU_ACCOUNTING && !NO_HZ_FULL
Select this option to enable more accurate task and CPU time
accounting. This is done by reading a CPU counter on each
kernel entry and exit and on transitions within the kernel
between system, softirq and hardirq state, so there is a
small performance impact. In the case of s390 or IBM POWER > 5,
this also enables accounting of stolen time on logically-partitioned
bool "Full dynticks CPU time accounting"
depends on HAVE_CONTEXT_TRACKING
depends on HAVE_VIRT_CPU_ACCOUNTING_GEN
depends on GENERIC_CLOCKEVENTS
Select this option to enable task and CPU time accounting on full
dynticks systems. This accounting is implemented by watching every
kernel-user boundaries using the context tracking subsystem.
The accounting is thus performed at the expense of some significant
For now this is only useful if you are working on the full
dynticks subsystem development.
If unsure, say N.
I marked a line through the last paragraph because it is outdated. "The full dynticks subsystem" has now been developed.
[*] TSC considerations
If an x86 CPU does not have a TSC, the kernel does not try to use any other hardware clock source for
IRQ_TIME_ACCOUNTING (or for
The code suggests that any available TSC is accepted. I don't know how well this works with CPUs which do not have
constant_tsc :-). Although I am 99.9% sure the relevant maintainers were aware of that issue, and would have asked why it was acceptable.
See native_sched_clock() and tsc_init():
* Fall back to jiffies if there's no TSC available:
* ( But note that we still use it if the TSC is marked
* unstable. We do this because unlike Time Of Day,
* the scheduler clock tolerates small errors and it's
* very important for it to be as fast as the platform
* can achieve it. )