[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 2/2] accel/tcg: replace phys_pc with asid in TB htable ke

From: Richard Henderson
Subject: Re: [RFC PATCH 2/2] accel/tcg: replace phys_pc with asid in TB htable key
Date: Fri, 24 Dec 2021 11:56:16 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

On 12/24/21 5:02 AM, Vasilev Oleg wrote:
On 12/23/2021 7:31 PM, Richard Henderson wrote:
On 12/22/21 8:50 AM, Oleg Vasilev wrote:
From: Oleg Vasilev <vasilev.oleg@huawei.com>

Using a physical pc requires to translate address every time next block
needs to be found and executed. This also contaminates TLB with code-related

Instead, I suggest we introduce an architecture-specific address space
identifier, and use it to distinguish between different AS's
translation blocks.

Why do you believe that asid is sufficient here?  You're not invalidating any 
more TBs
that I can see.  What happens when the kernel re-uses an asid?


Sorry, I had some comments for the patch, but forgot to put it in.

So, I think I interpret the term "asid" in some other sense, namely, an
identifier, which is constant during whole lifespan of an address space.
Same as PID in that sense. Do you think this is a viable approach?

No, I do not.

If we assume translation table wouldn't change during process life,
after the death of the process, all it address space would be anyway
unmapped and corresponding translation blocks would be invalidated.

While this assumption is often true, it certainly isn't universally true.
Consider the cases of dlclose, followed by another dlopen; or any JIT.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]