On Mon, Jun 27, 2016 at 07:31:29PM -0400, Rik van Riel wrote: > On Tue, 2016-06-28 at 01:21 +0200, Frederic Weisbecker wrote: > > On Wed, Jun 22, 2016 at 10:25:48PM -0400, r...@redhat.com wrote: > > > > > > From: Rik van Riel <r...@redhat.com> > > > > > > The CONFIG_VIRT_CPU_ACCOUNTING_GEN irq time tracking code does not > > > appear to currently work right. > > > > > > On CPUs that are nohz_full, people typically do not assign IRQs. > > Right, but they can still fire. At least one tick per second, plus > > the > > pinned timers, etc... > > > > > > > > > > > On the housekeeping CPU (when a system is booted up with > > > nohz_full), > > > sampling should work ok to determine irq and softirq time use, but > > > that only covers the housekeeping CPU itself, not the other > > > non-nohz_full CPUs. > > Hmm, every non-nohz_full CPUs, including the CPU 0, account the > > irqtime > > the same way: through the tick (and therefore can't account much of > > it). > > > But it will be subtracted from the user time, rather > than the idle time during which the irqs happened. > > Furthermore, we might well have 100 jiffies worth of > irq & softirq time on a CPU, and get just 1 jiffy > of userspace time, on systems acting like routers.
Indeed. > > > Remove the VTIME_GEN vtime irq time code. The next patch will > > > allow NO_HZ_FULL kernels to use the IRQ_TIME_ACCOUNTING code. > > I don't get the reason why we are doing this. Now arguably the > > irqtime > > accounting is probably not working as well as before since we > > switched to > > jiffy clock. But I still see some hard irqs accounted when > > account_irq_exit() > > is lucky enough to observe that jiffies changed since the beginning > > of > > the interrupt. > > > > So it's not entirely broken. I agree that we need to switch it to the > > generic irqtime accounting code but breaking the code now to > > reactivate it > > in a subsequent patch is prone to future bisection issues. > > Want me to merge patches 2 & 3 into one, so we immediately > start using the generic code and do not run into bisect > issues? Yeah that would be better. Thanks.
