4 ms·
CONFIG_IRQ_TIME_ACCOUNTING according to the docs: CONFIG_IRQ_TIME_ACCOUNTING: Select this option to enable fine granularity task irq time accounting. Th
by krzyk 6y ago
CONFIG_IRQ_TIME_ACCOUNTING according to the docs:
CONFIG_IRQ_TIME_ACCOUNTING:
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.
So I didn't enable this option in my kernels afraid of loosing performance on my laptop.
- tanelpoder 6y ago(Author here). It would be interesting to test the performance difference. I downloaded the source of one of my distro-provided kernels & recompiled it with different config setting (to compare perf with just one thing changed), but got into some trouble with my drivers and ran out of time. I would say that on your laptop, you probably wouldn't even notice a difference (as the "rdtsc" timestamp reading operations are pretty efficient & done entirely within a CPU). But with anything that can interact with external hardware million(s) of times per second (heavy SSD I/O in servers and moving large amounts of data over network), may see a minor (but measurable) hit. In my experience, when large amounts of CPU gets used by interrupt routines (either hardware or software interrupts), that more likely indicates some bug or configuration issue in a device driver or even some faulty hardware issue. edit: so, running "dmesg" and checking hardware health metrics (mceloc, EDAC) is a reasonable thing to do when interrupt storms & related CPU usage suddenly show up.