From: Scott Wood <oss@buserror.net>
To: Michael Ellerman <mpe@ellerman.id.au>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5] powerpc32: provide VIRT_CPU_ACCOUNTING
Date: Mon, 22 Feb 2016 20:15:18 -0600 [thread overview]
Message-ID: <1456193718.2463.142.camel@buserror.net> (raw)
In-Reply-To: <1456193080.16667.1.camel@ellerman.id.au>
On Tue, 2016-02-23 at 13:04 +1100, Michael Ellerman wrote:
> On Tue, 2016-02-16 at 15:21 -0600, Scott Wood wrote:
>
> > On Thu, 2016-02-11 at 17:16 +0100, Christophe Leroy wrote:
>
> > > 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 <christophe.leroy@c-s.fr>
> > > ---
> > > 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.
> > 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
next prev parent reply other threads:[~2016-02-23 2:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 16:16 [PATCH v5] powerpc32: provide VIRT_CPU_ACCOUNTING Christophe Leroy
2016-02-12 8:25 ` Denis Kirjanov
2016-02-14 20:40 ` Denis Kirjanov
2016-02-15 9:33 ` Christophe Leroy
2016-02-16 21:21 ` Scott Wood
2016-02-17 16:29 ` Christophe Leroy
2016-02-23 1:22 ` Scott Wood
2016-02-23 2:04 ` Michael Ellerman
2016-02-23 2:15 ` Scott Wood [this message]
2016-02-23 3:25 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1456193718.2463.142.camel@buserror.net \
--to=oss@buserror.net \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.