From: Peter Zijlstra <peterz@infradead.org>
To: Zhenyu Ye <yezhenyu2@huawei.com>
Cc: linux-arch@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
will.deacon@arm.com, linux-kernel@vger.kernel.org,
npiggin@gmail.com, arm@kernel.org, bp@alien8.de,
xiexiangyou@huawei.com, luto@kernel.org, schwidefsky@de.ibm.com,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
mingo@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC][Qusetion] the value of cleared_(ptes|pmds|puds|p4ds) in struct mmu_gather
Date: Mon, 30 Mar 2020 14:16:54 +0200 [thread overview]
Message-ID: <20200330121654.GL20696@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <fbb00ac0-9104-8d25-f225-7b3d1b17a01f@huawei.com>
On Sat, Mar 28, 2020 at 12:30:50PM +0800, Zhenyu Ye wrote:
> Hi all,
>
> commit a6d60245 "Track which levels of the page tables have been cleared"
> added cleared_(ptes|pmds|puds|p4ds) in struct mmu_gather, and the values
> of them are set in some places. For example:
>
> In include/asm-generic/tlb.h, pte_free_tlb() set the tlb->cleared_pmds:
> ---8<---
> #ifndef pte_free_tlb
> #define pte_free_tlb(tlb, ptep, address) \
> do { \
> __tlb_adjust_range(tlb, address, PAGE_SIZE); \
> tlb->freed_tables = 1; \
> tlb->cleared_pmds = 1; \
> __pte_free_tlb(tlb, ptep, address); \
> } while (0)
> #endif
> ---8<---
>
>
> However, in arch/s390/include/asm/tlb.h, pte_free_tlb() set the tlb->cleared_ptes:
> ---8<---
> static inline void pte_free_tlb(struct mmu_gather *tlb, pgtable_t pte,
> unsigned long address)
> {
> __tlb_adjust_range(tlb, address, PAGE_SIZE);
> tlb->mm->context.flush_mm = 1;
> tlb->freed_tables = 1;
> tlb->cleared_ptes = 1;
> /*
> * page_table_free_rcu takes care of the allocation bit masks
> * of the 2K table fragments in the 4K page table page,
> * then calls tlb_remove_table.
> */
> page_table_free_rcu(tlb, (unsigned long *) pte, address);
> }
> ---8<---
>
>
> In my view, the cleared_(ptes|pmds|puds) and (pte|pmd|pud)_free_tlb
> correspond one-to-one. So we should set cleared_ptes in pte_free_tlb(),
> then use it when needed.
So pte_free_tlb() clears a table of PTE entries, or a PMD level entity,
also see free_pte_range(). So the generic code makes sense to me. The
PTE level invalidations will have happened on tlb_remove_tlb_entry().
> I'm very confused about this. Which is wrong? Or is there something
> I understand wrong?
I agree the s390 case is puzzling, Martin does s390 need a PTE level
invalidate for removing a PTE table or was this a mistake?
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Zhenyu Ye <yezhenyu2@huawei.com>
Cc: npiggin@gmail.com, will.deacon@arm.com, mingo@kernel.org,
torvalds@linux-foundation.org, schwidefsky@de.ibm.com,
akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de,
Marc Zyngier <maz@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
arm@kernel.org, xiexiangyou@huawei.com
Subject: Re: [RFC][Qusetion] the value of cleared_(ptes|pmds|puds|p4ds) in struct mmu_gather
Date: Mon, 30 Mar 2020 14:16:54 +0200 [thread overview]
Message-ID: <20200330121654.GL20696@hirez.programming.kicks-ass.net> (raw)
Message-ID: <20200330121654.wJbb_TPDZQXoWuz2V0HqLRuxJ6pYItlc9bTCgd53er4@z> (raw)
In-Reply-To: <fbb00ac0-9104-8d25-f225-7b3d1b17a01f@huawei.com>
On Sat, Mar 28, 2020 at 12:30:50PM +0800, Zhenyu Ye wrote:
> Hi all,
>
> commit a6d60245 "Track which levels of the page tables have been cleared"
> added cleared_(ptes|pmds|puds|p4ds) in struct mmu_gather, and the values
> of them are set in some places. For example:
>
> In include/asm-generic/tlb.h, pte_free_tlb() set the tlb->cleared_pmds:
> ---8<---
> #ifndef pte_free_tlb
> #define pte_free_tlb(tlb, ptep, address) \
> do { \
> __tlb_adjust_range(tlb, address, PAGE_SIZE); \
> tlb->freed_tables = 1; \
> tlb->cleared_pmds = 1; \
> __pte_free_tlb(tlb, ptep, address); \
> } while (0)
> #endif
> ---8<---
>
>
> However, in arch/s390/include/asm/tlb.h, pte_free_tlb() set the tlb->cleared_ptes:
> ---8<---
> static inline void pte_free_tlb(struct mmu_gather *tlb, pgtable_t pte,
> unsigned long address)
> {
> __tlb_adjust_range(tlb, address, PAGE_SIZE);
> tlb->mm->context.flush_mm = 1;
> tlb->freed_tables = 1;
> tlb->cleared_ptes = 1;
> /*
> * page_table_free_rcu takes care of the allocation bit masks
> * of the 2K table fragments in the 4K page table page,
> * then calls tlb_remove_table.
> */
> page_table_free_rcu(tlb, (unsigned long *) pte, address);
> }
> ---8<---
>
>
> In my view, the cleared_(ptes|pmds|puds) and (pte|pmd|pud)_free_tlb
> correspond one-to-one. So we should set cleared_ptes in pte_free_tlb(),
> then use it when needed.
So pte_free_tlb() clears a table of PTE entries, or a PMD level entity,
also see free_pte_range(). So the generic code makes sense to me. The
PTE level invalidations will have happened on tlb_remove_tlb_entry().
> I'm very confused about this. Which is wrong? Or is there something
> I understand wrong?
I agree the s390 case is puzzling, Martin does s390 need a PTE level
invalidate for removing a PTE table or was this a mistake?
next prev parent reply other threads:[~2020-03-30 12:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-28 4:30 [RFC][Qusetion] the value of cleared_(ptes|pmds|puds|p4ds) in struct mmu_gather Zhenyu Ye
2020-03-28 4:30 ` Zhenyu Ye
2020-03-30 12:16 ` Peter Zijlstra [this message]
2020-03-30 12:16 ` Peter Zijlstra
2020-03-31 8:15 ` Zhenyu Ye
2020-04-08 8:51 ` Christian Borntraeger
2020-04-20 16:20 ` Gerald Schaefer
2020-04-20 16:20 ` Gerald Schaefer
2020-04-14 7:05 ` Christian Borntraeger
2020-04-14 7:05 ` Christian Borntraeger
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=20200330121654.GL20696@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=arm@kernel.org \
--cc=bp@alien8.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=maz@kernel.org \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=schwidefsky@de.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=xiexiangyou@huawei.com \
--cc=yezhenyu2@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).