| Message ID | 20170519144112.15649-1-anton@ozlabs.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
Anton Blanchard <anton@ozlabs.org> writes: > From: Anton Blanchard <anton@samba.org> > > ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE > by default. The overhead of this option is extremely high - a context > switch microbenchmark using sched_yield() is almost 20% slower. Running on what? It should all be nop'ed out unless you're on a platform that needs it (SPLPAR). > To get finer grained user/hardirq/softirq statitics, the > IRQ_TIME_ACCOUNTING option can be used instead, which has much lower > overhead. Can it? We don't select HAVE_IRQ_TIME_ACCOUNTING, so AFAICS it can't be enabled. Doesn't dropping this mean we never count stolen time? cheers
On Mon, 22 May 2017 14:15:57 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote: > Anton Blanchard <anton@ozlabs.org> writes: > > > From: Anton Blanchard <anton@samba.org> > > > > ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE > > by default. The overhead of this option is extremely high - a context > > switch microbenchmark using sched_yield() is almost 20% slower. > > Running on what? It should all be nop'ed out unless you're on a platform > that needs it (SPLPAR). Not ACCOUNT_CPU_USER_ENTRY/EXIT, which adds a fair cost to kernel entry/exit (my notes say ~70 cycles on getppid() out of 3-4 hundred). > > > To get finer grained user/hardirq/softirq statitics, the > > IRQ_TIME_ACCOUNTING option can be used instead, which has much lower > > overhead. > > Can it? We don't select HAVE_IRQ_TIME_ACCOUNTING, so AFAICS it can't be > enabled. > > Doesn't dropping this mean we never count stolen time? > > cheers
Hi Michael, > > ppc64 is the only architecture that turns on > > VIRT_CPU_ACCOUNTING_NATIVE by default. The overhead of this option > > is extremely high - a context switch microbenchmark using > > sched_yield() is almost 20% slower. > > Running on what? It should all be nop'ed out unless you're on a > platform that needs it (SPLPAR). POWERNV native. We don't nop out all the vtime_account_* gunk do we? It is all those functions that are a large part of the problem. > > To get finer grained user/hardirq/softirq statitics, the > > IRQ_TIME_ACCOUNTING option can be used instead, which has much lower > > overhead. > > Can it? We don't select HAVE_IRQ_TIME_ACCOUNTING, so AFAICS it can't > be enabled. I have a separate patch to enable it. > Doesn't dropping this mean we never count stolen time? Perhaps. Do we have any applications left that care? Anton
Le 19/05/2017 à 16:41, Anton Blanchard a écrit : > From: Anton Blanchard <anton@samba.org> > > ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE > by default. The overhead of this option is extremely high - a context > switch microbenchmark using sched_yield() is almost 20% slower. > > To get finer grained user/hardirq/softirq statitics, the > IRQ_TIME_ACCOUNTING option can be used instead, which has much lower > overhead. Does IRQ_TIME_ACCOUNTING allow the same granularity as VIRT_CPU_ACCOUNTING_NATIVE ? I've quickly looked into the source, it seems that this option still accounts based on time ticks. On a hardware doing mainly VoIP handling, the processes run a few ms every 20 ms. With TICK_CPU_ACCOUNTING and a 10ms tick, the processes either appear with 50% CPU or almost 0%. Would it be more precise with IRQ_TIME_ACCOUNTING ? Christophe > > As such, disable this option by default. If a user really wants it, > they can still enable it manually. > > Signed-off-by: Anton Blanchard <anton@samba.org> > --- > init/Kconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index 1d3475fc9496..a5c30acc1ede 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -342,8 +342,7 @@ config VIRT_CPU_ACCOUNTING > > choice > prompt "Cputime accounting" > - default TICK_CPU_ACCOUNTING if !PPC64 > - default VIRT_CPU_ACCOUNTING_NATIVE if PPC64 > + default TICK_CPU_ACCOUNTING > > # Kind of a stub config for the pure tick based cputime accounting > config TICK_CPU_ACCOUNTING >
Le 22/05/2017 à 07:13, Anton Blanchard a écrit : > Hi Michael, > >>> ppc64 is the only architecture that turns on >>> VIRT_CPU_ACCOUNTING_NATIVE by default. The overhead of this option >>> is extremely high - a context switch microbenchmark using >>> sched_yield() is almost 20% slower. >> >> Running on what? It should all be nop'ed out unless you're on a >> platform that needs it (SPLPAR). > > POWERNV native. We don't nop out all the vtime_account_* gunk do we? It > is all those functions that are a large part of the problem. > >>> To get finer grained user/hardirq/softirq statitics, the >>> IRQ_TIME_ACCOUNTING option can be used instead, which has much lower >>> overhead. >> >> Can it? We don't select HAVE_IRQ_TIME_ACCOUNTING, so AFAICS it can't >> be enabled. > > I have a separate patch to enable it. > >> Doesn't dropping this mean we never count stolen time? > > Perhaps. Do we have any applications left that care? > This patch has been superseded by Nick's patch https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220525081346.871535-1-npiggin@gmail.com/ Christophe
diff --git a/init/Kconfig b/init/Kconfig index 1d3475fc9496..a5c30acc1ede 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -342,8 +342,7 @@ config VIRT_CPU_ACCOUNTING choice prompt "Cputime accounting" - default TICK_CPU_ACCOUNTING if !PPC64 - default VIRT_CPU_ACCOUNTING_NATIVE if PPC64 + default TICK_CPU_ACCOUNTING # Kind of a stub config for the pure tick based cputime accounting config TICK_CPU_ACCOUNTING