[PATCH] powerpc/64: Use tick accounting by default

From: Anton Blanchard <redacted>

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.

As such, disable this option by default. If a user really wants it,
they can still enable it manually.

Signed-off-by: Anton Blanchard <redacted>
---
 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

-- 
2.11.0

Anton Blanchard [off-list ref] writes:

From: Anton Blanchard <redacted>

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 [off-list ref] wrote:

Anton Blanchard [off-list ref] writes:

quoted

From: Anton Blanchard <redacted>

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).

quoted

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,

quoted

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.

quoted

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 22/05/2017 à 07:13, Anton Blanchard a écrit :

Hi Michael,

quoted

quoted

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.

quoted

quoted

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.

quoted

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

Le 19/05/2017 à 16:41, Anton Blanchard a écrit :

From: Anton Blanchard <redacted>

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