2016-08-09 22:06 GMT+08:00 Rik van Riel <r...@redhat.com>: > On Tue, 2016-08-09 at 11:59 +0800, Wanpeng Li wrote: >> Hi Rik, >> 2016-07-13 22:50 GMT+08:00 Frederic Weisbecker <fweis...@gmail.com>: >> > From: Rik van Riel <r...@redhat.com> >> > >> > Currently, if there was any irq or softirq time during 'ticks' >> > jiffies, the entire period will be accounted as irq or softirq >> > time. >> > >> > This is inaccurate if only a subset of the time was actually spent >> > handling irqs, and could conceivably mis-count all of the ticks >> > during >> > a period as irq time, when there was some irq and some softirq >> > time. >> > >> > This can actually happen when irqtime_account_process_tick is >> > called >> > from account_idle_ticks, which can pass a larger number of ticks >> > down >> > all at once. >> > >> > Fix this by changing irqtime_account_hi_update, >> > irqtime_account_si_update, >> > and steal_account_process_ticks to work with cputime_t time units, >> > and >> > return the amount of time spent in each mode. >> >> Do we need to minus st cputime from idle cputime in >> account_idle_ticks() when noirqtime is true? I try to add this logic >> w/ noirqtime and idle=poll boot parameter for a full dynticks guest, >> however, there is no difference, where I miss? > > Yes, you are right. The code in account_idle_ticks() > could use the same treatment. > > I am not sure why it would not work, though...
Actually I observed a regression caused by this patch. I use a i5 laptop, 4 pCPUs, 4vCPUs for one full dynticks guest, there are four cpu hog processes(for loop) running in the guest, I hot-unplug the pCPUs on host one by one until there is only one left, then observe the top in guest, there are 100% st for cpu0(housekeeping), and 75% st for other cpus(nohz full). However, w/o this patch, 75% for all the four cpus. I try to figure out this recently, any tip is a great appreciated. :) Regards, Wapeng Li
