[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJF2gTTmFq3yYa9UrdZRAFwJgC=KmKTe2_NFy_UZBUQovqQJPg@mail.gmail.com>
Date: Wed, 19 Jun 2019 20:18:04 +0800
From: Guo Ren <guoren@...nel.org>
To: Arnd Bergmann <arnd@...db.de>, Will Deacon <will.deacon@....com>
Cc: linux-kernel@...r.kernel.org, Julien Grall <julien.grall@....com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
aou@...s.berkeley.edu, gary@...yguo.net, Atish.Patra@....com,
hch@...radead.org, paul.walmsley@...ive.com, rppt@...ux.ibm.com,
linux-riscv@...ts.infradead.org, Anup Patel <anup.Patel@....com>,
Palmer Dabbelt <palmer@...ive.com>, suzuki.poulose@....com,
Marc Zyngier <marc.zyngier@....com>, catalin.marinas@....com,
julien.thierry@....com, christoffer.dall@....com,
james.morse@....com
Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a
separate file
On Wed, Jun 19, 2019 at 5:12 PM Will Deacon <will.deacon@....com> wrote:
>
> On Wed, Jun 19, 2019 at 09:54:21AM +0100, Julien Grall wrote:
> > On 6/19/19 9:07 AM, Guo Ren wrote:
> > > You forgot CCing C-SKY folks :P
> >
> > I wasn't aware you could be interested :).
> >
> > > Move arm asid allocator code in a generic one is a agood idea, I've
> > > made a patchset for C-SKY and test is on processing, See:
> > > https://lore.kernel.org/linux-csky/1560930553-26502-1-git-send-email-guoren@kernel.org/
> > >
> > > If you plan to seperate it into generic one, I could co-work with you.
> >
> > Was the ASID allocator work out of box on C-Sky? If so, I can easily move
> > the code in a generic place (maybe lib/asid.c).
>
> This is one place where I'd actually prefer not to go down the route of
> making the code generic. Context-switching and low-level TLB management
> is deeply architecture-specific and I worry that by trying to make this
> code common, we run the real risk of introducing subtle bugs on some
> architecture every time it is changed.
"Add generic asid code" and "move arm's into generic" are two things.
We could do
first and let architecture's maintainer to choose.
> Furthermore, the algorithm we use
> on arm64 is designed to scale to large systems using DVM and may well be
> too complex and/or sub-optimal for architectures with different system
> topologies or TLB invalidation mechanisms.
It's just a asid algorithm not very complex and there is a callback
for architecture to define their
own local hart tlb flush. Seems it has nothing with DVM or tlb
broadcast mechanism.
>
> It's not a lot of code, so I don't see that it's a big deal to keep it
> under arch/arm64.
Yes, I think that's ok for arm64.
Hi Arnd,
What do you think about adding generic asid code for arch selection?
Best Regards
Guo Ren
Powered by blists - more mailing lists