From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
"maz@kernel.org" <maz@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 3/3] kvm/arm: Align the VMID allocation with the arm64 ASID one
Date: Fri, 23 Jul 2021 16:49:46 +0100 [thread overview]
Message-ID: <53f9359d-d3ac-5a3c-1e29-9fb7e9fda22c@arm.com> (raw)
In-Reply-To: <20210722153814.GA12566@willie-the-truck>
Hi Will,
On 7/22/21 4:38 PM, Will Deacon wrote:
> Hi Vladimir,
>
> On Thu, Jul 22, 2021 at 04:22:26PM +0100, Vladimir Murzin wrote:
>> On 7/22/21 10:50 AM, Will Deacon wrote:
>>> As an aside: I'm more and more inclined to rip out the CnP stuff given
>>> that it doesn't appear to being any benefits, but does have some clear
>>> downsides. Perhaps something for next week.
>>
>> Can you please clarify what do you mean by "it doesn't appear to being any
>> benefits"? IIRC, Cortex-A65 implements CnP hint and I've heard that some
>> payloads seen improvement...
>
> Has anybody taped that out? I'd have thought building an SMT design in 2021
> is a reasonably courageous thing to do.
As you said three can be niche for that...
>
> The issue I'm getting at is that modern cores seem to advertise CnP even
> if they ignore it internally, maybe because of some big/little worries?
Should we employ CPU errata framework for such cores to demote CnP?
> That would be fine if it didn't introduce complexity and overhead to the
> kernel, but it does and therefore I think we should rip it out (or at
> least stick it behind a "default n" config option if there are some niche
> users).
"default n" still better then no code at all :)
Cheers
Vladimir
>
> There are also open questions as to exactly what CnP does because the
> architecture is not clear at all (for example TTBRx_EL1.CnP is permitted
> to be cached in a TLB).
>
> CHeers,
>
> Will
>
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Will Deacon <will@kernel.org>
Cc: "jean-philippe@linaro.org" <jean-philippe@linaro.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
Linuxarm <linuxarm@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"maz@kernel.org" <maz@kernel.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 3/3] kvm/arm: Align the VMID allocation with the arm64 ASID one
Date: Fri, 23 Jul 2021 16:49:46 +0100 [thread overview]
Message-ID: <53f9359d-d3ac-5a3c-1e29-9fb7e9fda22c@arm.com> (raw)
In-Reply-To: <20210722153814.GA12566@willie-the-truck>
Hi Will,
On 7/22/21 4:38 PM, Will Deacon wrote:
> Hi Vladimir,
>
> On Thu, Jul 22, 2021 at 04:22:26PM +0100, Vladimir Murzin wrote:
>> On 7/22/21 10:50 AM, Will Deacon wrote:
>>> As an aside: I'm more and more inclined to rip out the CnP stuff given
>>> that it doesn't appear to being any benefits, but does have some clear
>>> downsides. Perhaps something for next week.
>>
>> Can you please clarify what do you mean by "it doesn't appear to being any
>> benefits"? IIRC, Cortex-A65 implements CnP hint and I've heard that some
>> payloads seen improvement...
>
> Has anybody taped that out? I'd have thought building an SMT design in 2021
> is a reasonably courageous thing to do.
As you said three can be niche for that...
>
> The issue I'm getting at is that modern cores seem to advertise CnP even
> if they ignore it internally, maybe because of some big/little worries?
Should we employ CPU errata framework for such cores to demote CnP?
> That would be fine if it didn't introduce complexity and overhead to the
> kernel, but it does and therefore I think we should rip it out (or at
> least stick it behind a "default n" config option if there are some niche
> users).
"default n" still better then no code at all :)
Cheers
Vladimir
>
> There are also open questions as to exactly what CnP does because the
> architecture is not clear at all (for example TTBRx_EL1.CnP is permitted
> to be cached in a TLB).
>
> CHeers,
>
> Will
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
"maz@kernel.org" <maz@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 3/3] kvm/arm: Align the VMID allocation with the arm64 ASID one
Date: Fri, 23 Jul 2021 16:49:46 +0100 [thread overview]
Message-ID: <53f9359d-d3ac-5a3c-1e29-9fb7e9fda22c@arm.com> (raw)
In-Reply-To: <20210722153814.GA12566@willie-the-truck>
Hi Will,
On 7/22/21 4:38 PM, Will Deacon wrote:
> Hi Vladimir,
>
> On Thu, Jul 22, 2021 at 04:22:26PM +0100, Vladimir Murzin wrote:
>> On 7/22/21 10:50 AM, Will Deacon wrote:
>>> As an aside: I'm more and more inclined to rip out the CnP stuff given
>>> that it doesn't appear to being any benefits, but does have some clear
>>> downsides. Perhaps something for next week.
>>
>> Can you please clarify what do you mean by "it doesn't appear to being any
>> benefits"? IIRC, Cortex-A65 implements CnP hint and I've heard that some
>> payloads seen improvement...
>
> Has anybody taped that out? I'd have thought building an SMT design in 2021
> is a reasonably courageous thing to do.
As you said three can be niche for that...
>
> The issue I'm getting at is that modern cores seem to advertise CnP even
> if they ignore it internally, maybe because of some big/little worries?
Should we employ CPU errata framework for such cores to demote CnP?
> That would be fine if it didn't introduce complexity and overhead to the
> kernel, but it does and therefore I think we should rip it out (or at
> least stick it behind a "default n" config option if there are some niche
> users).
"default n" still better then no code at all :)
Cheers
Vladimir
>
> There are also open questions as to exactly what CnP does because the
> architecture is not clear at all (for example TTBRx_EL1.CnP is permitted
> to be cached in a TLB).
>
> CHeers,
>
> Will
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-23 15:49 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-16 15:56 [PATCH v2 0/3] kvm/arm: New VMID allocator based on asid Shameer Kolothum
2021-06-16 15:56 ` Shameer Kolothum
2021-06-16 15:56 ` Shameer Kolothum
2021-06-16 15:56 ` [PATCH v2 1/3] arch/arm64: Introduce a capability to tell whether 16-bit VMID is available Shameer Kolothum
2021-06-16 15:56 ` Shameer Kolothum
2021-06-16 15:56 ` Shameer Kolothum
2021-07-21 15:23 ` Will Deacon
2021-07-21 15:23 ` Will Deacon
2021-07-21 15:23 ` Will Deacon
2021-07-22 6:24 ` Shameerali Kolothum Thodi
2021-07-22 6:24 ` Shameerali Kolothum Thodi
2021-07-22 6:24 ` Shameerali Kolothum Thodi
2021-06-16 15:56 ` [PATCH v2 2/3] kvm/arm: Introduce a new vmid allocator for KVM Shameer Kolothum
2021-06-16 15:56 ` Shameer Kolothum
2021-06-16 15:56 ` Shameer Kolothum
2021-07-21 16:06 ` Will Deacon
2021-07-21 16:06 ` Will Deacon
2021-07-21 16:06 ` Will Deacon
2021-07-22 6:34 ` Shameerali Kolothum Thodi
2021-07-22 6:34 ` Shameerali Kolothum Thodi
2021-07-22 6:34 ` Shameerali Kolothum Thodi
2021-06-16 15:56 ` [PATCH v2 3/3] kvm/arm: Align the VMID allocation with the arm64 ASID one Shameer Kolothum
2021-06-16 15:56 ` Shameer Kolothum
2021-06-16 15:56 ` Shameer Kolothum
2021-07-21 16:31 ` Will Deacon
2021-07-21 16:31 ` Will Deacon
2021-07-21 16:31 ` Will Deacon
2021-07-22 6:45 ` Shameerali Kolothum Thodi
2021-07-22 6:45 ` Shameerali Kolothum Thodi
2021-07-22 6:45 ` Shameerali Kolothum Thodi
2021-07-22 9:11 ` Quentin Perret
2021-07-22 9:11 ` Quentin Perret
2021-07-22 9:11 ` Quentin Perret
2021-07-22 19:33 ` Marco Elver
2021-07-22 19:33 ` Marco Elver
2021-07-22 19:33 ` Marco Elver
2021-07-22 9:50 ` Will Deacon
2021-07-22 9:50 ` Will Deacon
2021-07-22 9:50 ` Will Deacon
2021-07-22 15:22 ` Vladimir Murzin
2021-07-22 15:22 ` Vladimir Murzin
2021-07-22 15:22 ` Vladimir Murzin
2021-07-22 15:38 ` Will Deacon
2021-07-22 15:38 ` Will Deacon
2021-07-22 15:38 ` Will Deacon
2021-07-23 15:49 ` Vladimir Murzin [this message]
2021-07-23 15:49 ` Vladimir Murzin
2021-07-23 15:49 ` Vladimir Murzin
2021-07-13 7:07 ` [PATCH v2 0/3] kvm/arm: New VMID allocator based on asid Shameerali Kolothum Thodi
2021-07-13 7:07 ` Shameerali Kolothum Thodi
2021-07-13 7:07 ` Shameerali Kolothum Thodi
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=53f9359d-d3ac-5a3c-1e29-9fb7e9fda22c@arm.com \
--to=vladimir.murzin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=jean-philippe@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=maz@kernel.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=will@kernel.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.