On Mon, 1 Dec 2014 17:15:45 +0100 Frederic Weisbecker <[email protected]> wrote:
> On Mon, Dec 01, 2014 at 03:41:28PM +0100, Martin Schwidefsky wrote: > > On Fri, 28 Nov 2014 19:23:54 +0100 > > Frederic Weisbecker <[email protected]> wrote: > > > > > The irqtime is accounted is nsecs and stored in > > > cpu_irq_time.hardirq_time and cpu_irq_time.softirq_time. Once the > > > accumulated amount reaches a new jiffy, this one gets accounted to the > > > kcpustat. > > > > > > This was necessary when kcpustat was stored in cputime_t, which could at > > > worst have a jiffies granularity. But now kcpustat is stored in nsecs > > > so this whole discretization game with temporary irqtime storage has > > > become unnecessary. > > > > > > We can now directly account the irqtime to the kcpustat. > > > > Isn't the issue here that two different approaches to cputime accounting > > get mixed here? On the one hand a cputime_t based on jiffies and on the > > other CONFIG_IRQ_TIME_ACCOUNTING which uses sched_clock_cpu() to create > > the accounting deltas. > > There is no other way really because cputime_t can wrap very low granularity > time unit such as jiffies. And there is no way to account irqtime with jiffies > since IRQ duration is supposed to be below 1 ms. > > So irqtime is accounted with a high precision clock, nsecs based and > periodically > accounted as cputime_t once we accumulate enough for a cputime_t unit. > > And turning cputime_t to nsecs simplifies that. What would happen if cputime_t gets defined to nsecs for a jiffies based system? The fact that a regular tick is used to create a cputime delta does not force us to define cputime_t as a jiffies counter, no? -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
