| Message ID | 20200324134534.1570-1-yezhenyu2@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: tlb: add support for TTL feature | expand |
On Tue, Mar 24, 2020 at 09:45:28PM +0800, Zhenyu Ye wrote: > In order to reduce the cost of TLB invalidation, the ARMv8.4 TTL > feature allows TLBs to be issued with a level allowing for quicker > invalidation. This series provide support for this feature. > > Patch 1 and Patch 2 was provided by Marc on his NV series[1] patches, > which detect the TTL feature and add __tlbi_level interface. I realy hate how it makes vma->vm_flags more important for tlbi.
Hi Peter, On 2020/3/24 23:01, Peter Zijlstra wrote: > On Tue, Mar 24, 2020 at 09:45:28PM +0800, Zhenyu Ye wrote: >> In order to reduce the cost of TLB invalidation, the ARMv8.4 TTL >> feature allows TLBs to be issued with a level allowing for quicker >> invalidation. This series provide support for this feature. >> >> Patch 1 and Patch 2 was provided by Marc on his NV series[1] patches, >> which detect the TTL feature and add __tlbi_level interface. > > I realy hate how it makes vma->vm_flags more important for tlbi. > Thanks for your review. The tlbi interfaces only have two parameters: vma and addr. If we try to not use vma->vm_flags, we may should have to add a parameter to some of these interfaces(such as flush_tlb_range), which are common to all architectures. I'm not sure if this is feasible, because this feature is only supported by ARM64 currently. Thanks, Zhenyu
On Wed, Mar 25, 2020 at 12:49:45PM +0800, Zhenyu Ye wrote: > Hi Peter, > > On 2020/3/24 23:01, Peter Zijlstra wrote: > > On Tue, Mar 24, 2020 at 09:45:28PM +0800, Zhenyu Ye wrote: > >> In order to reduce the cost of TLB invalidation, the ARMv8.4 TTL > >> feature allows TLBs to be issued with a level allowing for quicker > >> invalidation. This series provide support for this feature. > >> > >> Patch 1 and Patch 2 was provided by Marc on his NV series[1] patches, > >> which detect the TTL feature and add __tlbi_level interface. > > > > I realy hate how it makes vma->vm_flags more important for tlbi. > > > > Thanks for your review. > > The tlbi interfaces only have two parameters: vma and addr. If we > try to not use vma->vm_flags, we may should have to add a parameter > to some of these interfaces(such as flush_tlb_range), which are > common to all architectures. > > I'm not sure if this is feasible, because this feature is only > supported by ARM64 currently. Power (p9-radix) also has level dependent invalidation instructions, so at the very least you can hook them up as well.
Hi Zhenyu, On 3/24/20 1:45 PM, Zhenyu Ye wrote: > In order to reduce the cost of TLB invalidation, the ARMv8.4 TTL > feature allows TLBs to be issued with a level allowing for quicker > invalidation. This series provide support for this feature. > > Patch 1 and Patch 2 was provided by Marc on his NV series[1] patches, > which detect the TTL feature and add __tlbi_level interface. How does this interact with THP? (I don't see anything on that in the series.) With THP, there is no one answer to the size of mapping in a VMA. This is a problem because the arm-arm has in "Translation table level hints" in D5.10.2 of DDI0487E.a: | If an incorrect value for the entry being invalidated by the | instruction is specified in the TTL field, then no entries are | required by the architecture to be invalidated from the TLB. If we get it wrong, not TLB maintenance occurs! Unless THP leaves its fingerprints on the vma, I think you can only do this for VMA types that THP can't mess with. (see transparent_hugepage_enabled()) Thanks, James
On Wed, Mar 25, 2020 at 04:15:58PM +0000, James Morse wrote: > Hi Zhenyu, > > On 3/24/20 1:45 PM, Zhenyu Ye wrote: > > In order to reduce the cost of TLB invalidation, the ARMv8.4 TTL > > feature allows TLBs to be issued with a level allowing for quicker > > invalidation. This series provide support for this feature. > > > > Patch 1 and Patch 2 was provided by Marc on his NV series[1] patches, > > which detect the TTL feature and add __tlbi_level interface. > > How does this interact with THP? > (I don't see anything on that in the series.) > > With THP, there is no one answer to the size of mapping in a VMA. > This is a problem because the arm-arm has in "Translation table level > hints" in D5.10.2 of DDI0487E.a: > | If an incorrect value for the entry being invalidated by the > | instruction is specified in the TTL field, then no entries are > | required by the architecture to be invalidated from the TLB. > > If we get it wrong, not TLB maintenance occurs! > > Unless THP leaves its fingerprints on the vma, I think you can only do > this for VMA types that THP can't mess with. (see > transparent_hugepage_enabled()) The convention way to deal with that is to issue the TBLI for all possible sizes. Power9 has all this, please look there.
Hi James, On 2020/3/26 0:15, James Morse wrote: > Hi Zhenyu, > > On 3/24/20 1:45 PM, Zhenyu Ye wrote: >> In order to reduce the cost of TLB invalidation, the ARMv8.4 TTL >> feature allows TLBs to be issued with a level allowing for quicker >> invalidation. This series provide support for this feature. >> >> Patch 1 and Patch 2 was provided by Marc on his NV series[1] patches, >> which detect the TTL feature and add __tlbi_level interface. > > How does this interact with THP? > (I don't see anything on that in the series.) > > With THP, there is no one answer to the size of mapping in a VMA. > This is a problem because the arm-arm has in "Translation table level > hints" in D5.10.2 of DDI0487E.a: > | If an incorrect value for the entry being invalidated by the > | instruction is specified in the TTL field, then no entries are > | required by the architecture to be invalidated from the TLB. > > If we get it wrong, not TLB maintenance occurs! > Thanks for your review. With THP, we should update the TTL value after the page collapse and merge. If not sure what it should be, we can set it to 0 to avoid "no TLB maintenance occur" problem. The Table D5-53 in DDI0487E.a says: | when TTL[1:0] is 0b00: | This value is reserved, and hardware should treat this as if TTL[3:2] is 0b00 | when TTL[3:2] is 0b00: | Hardware must assume that the entry can be from any level. > Unless THP leaves its fingerprints on the vma, I think you can only do > this for VMA types that THP can't mess with. (see > transparent_hugepage_enabled()) > I will try to add struct mmu_gather to TLBI interfaces, which has enough info to track tlb's level. See in next patch version! Thanks, Zhenyu .
On 2020/3/25 21:32, Peter Zijlstra wrote: > On Wed, Mar 25, 2020 at 12:49:45PM +0800, Zhenyu Ye wrote: >> Hi Peter, >> >> On 2020/3/24 23:01, Peter Zijlstra wrote: >>> On Tue, Mar 24, 2020 at 09:45:28PM +0800, Zhenyu Ye wrote: >>>> In order to reduce the cost of TLB invalidation, the ARMv8.4 TTL >>>> feature allows TLBs to be issued with a level allowing for quicker >>>> invalidation. This series provide support for this feature. >>>> >>>> Patch 1 and Patch 2 was provided by Marc on his NV series[1] patches, >>>> which detect the TTL feature and add __tlbi_level interface. >>> >>> I realy hate how it makes vma->vm_flags more important for tlbi. >>> >> >> Thanks for your review. >> >> The tlbi interfaces only have two parameters: vma and addr. If we >> try to not use vma->vm_flags, we may should have to add a parameter >> to some of these interfaces(such as flush_tlb_range), which are >> common to all architectures. >> >> I'm not sure if this is feasible, because this feature is only >> supported by ARM64 currently. > > Power (p9-radix) also has level dependent invalidation instructions, so > at the very least you can hook them up as well. > > . > Thanks, I will push my next version soon. Zhenyu .