On Wed, Jun 19, 2019 at 08:18:04PM +0800, Guo Ren wrote: > On Wed, Jun 19, 2019 at 5:12 PM Will Deacon <will.deacon@xxxxxxx> wrote: > > 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. If I understand the proposal being discussed, it involves basing that generic ASID allocation code around the arm64 implementation which I don't necessarily think is a good starting point. > > 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. I'm pleased that you think the algorithm is not very complex, but I'm also worried that you might not have fully understood some of its finer details. The reason I mention DVM and TLB broadcasting is because, depending on the mechanisms in your architecture relating to those, it may be strictly required that all concurrently running threads of a process have the same ASID at any given point in time, or it may be that you really don't care. If you don't care, then the arm64 allocator is over-engineered and likely inefficient for your system. If you do care, then it's worth considering whether a lock is sufficient around the allocator if you don't expect high core counts. Another possibility is that you end up using only one ASID and invalidating the local TLB on every context switch. Yet another design would be to manage per-cpu ASID pools. So rather than blindly copying the arm64 code, I suggest sitting down and designing something that fits to your architecture instead. You may end up with something that is both simpler and more efficient. Will _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
