On Tue, 2016-02-23 at 13:04 +1100, Michael Ellerman wrote:

On Tue, 2016-02-16 at 15:21 -0600, Scott Wood wrote:

quoted

On Thu, 2016-02-11 at 17:16 +0100, Christophe Leroy wrote:

quoted

quoted

This patch provides VIRT_CPU_ACCOUTING to PPC32 architecture.
PPC32 doesn't have the PACA structure, so we use the task_info
structure to store the accounting data.

In order to reuse on PPC32 the PPC64 functions, all u64 data has
been replaced by 'unsigned long' so that it is u32 on PPC32 and
u64 on PPC64

Signed-off-by: Christophe Leroy <redacted>
---
Changes in v3: unlike previous version of the patch that was inspired
from IA64 architecture, this new version tries to reuse as much as
possible the PPC64 implementation.

PPC32 doesn't have PACA and past discusion on v2 version has shown
that it is not worth implementing a PACA in PPC32 architecture
(see below benh opinion)

benh: PACA is actually a data structure and you really really don't want
it
on ppc32 :-) Having a register point to current works, having a register
point to per-cpu data instead works too (ie, change what we do today),
but don't introduce a PACA *please* :-)

And Ben never replied to my reply at the time:

"What is special about 64-bit that warrants doing things differently from
32
-bit?

Nothing. It's just historical cruft. But we're not realistically going to
get
rid of it anytime soon on 64-bit.

I wasn't suggesting getting rid of it on 64-bit, but rather adding it on 32
-bit, to hold things that are used by both.  I was confused by the vehemence
of Ben's objection.

quoted

What is the difference between PACA and "per-cpu data", other than the
obscure name?"

Not much. The pacas are allocated differently to per-cpu data, they're
available earlier in boot etc.

Ah, I was thinking of the general concept of per-cpu data, not the specific
mechanism that Linux implements in percpu.h etc.

 What we'd like is to have r13 point to the
per-cpu data area, and then the contents of the paca could just be regular
per-cpu data. But like I said above that's a big change.

That change seems orthogonal to the question of making the mechanism available
on 32-bit to ease unification of code which uses it.

-Scott