From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Zhenyu Ye <yezhenyu2@huawei.com>,
npiggin@gmail.com, will.deacon@arm.com, mingo@kernel.org,
torvalds@linux-foundation.org, Vasily Gorbik <gor@linux.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,
linux-s390 <linux-s390@vger.kernel.org>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>
Subject: Re: [RFC][Qusetion] the value of cleared_(ptes|pmds|puds|p4ds) in struct mmu_gather
Date: Mon, 20 Apr 2020 18:20:23 +0200 [thread overview]
Message-ID: <20200420182023.6b8e143a@thinkpad> (raw)
In-Reply-To: <68affa6e-44cd-37e3-cdfc-8eec31c4097e@de.ibm.com>
On Wed, 8 Apr 2020 10:51:59 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
[...]
>
> adding Gerald and Vasily. Gerald can you have a look?
>
> >>
> >>
> >> 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?
> >
Peter is right, the PTE level invalidations will happen before. For
s390, not exactly at the tlb_remove_tlb_entry() itself, since
__tlb_remove_tlb_entry() is not defined, but rather directly at the
preceding ptep_get_and_clear(). I think this also the reason why we
cannot easily optimize for larger granularity.
Anyway, pte_free_tlb() will then later only take care of freeing
the page table page, no further PTE level clearing/invalidation
needed. I see no reason why s390 should behave differently from
the generic code, wrt to cleared_pxds setting in pxd_free_tlb().
So I guess this was an "off-by-one" mistake in commit 9de7d833e3708
("s390/tlb: Convert to generic mmu_gather"), since the other
pxd_free_tlb() functions also show similar puzzling behavior.
Not consistently off-by-one though, as pmd_free_tlb() seems
to behave correctly, setting tlb->cleared_puds = 1, similar to
generic code.
That was a very nice catch, Zhenyu, thanks for reporting!
We are not yet making use of the tlb->cleared_pxds for s390, but
we would certainly have stumbled over this if we ever tried.
Will send a patch to make s390 behave like generic code here.
Regards,
Gerald
WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-arch@vger.kernel.org,
linux-s390 <linux-s390@vger.kernel.org>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Zhenyu Ye <yezhenyu2@huawei.com>,
Peter Zijlstra <peterz@infradead.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,
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, 20 Apr 2020 18:20:23 +0200 [thread overview]
Message-ID: <20200420182023.6b8e143a@thinkpad> (raw)
In-Reply-To: <68affa6e-44cd-37e3-cdfc-8eec31c4097e@de.ibm.com>
On Wed, 8 Apr 2020 10:51:59 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
[...]
>
> adding Gerald and Vasily. Gerald can you have a look?
>
> >>
> >>
> >> 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?
> >
Peter is right, the PTE level invalidations will happen before. For
s390, not exactly at the tlb_remove_tlb_entry() itself, since
__tlb_remove_tlb_entry() is not defined, but rather directly at the
preceding ptep_get_and_clear(). I think this also the reason why we
cannot easily optimize for larger granularity.
Anyway, pte_free_tlb() will then later only take care of freeing
the page table page, no further PTE level clearing/invalidation
needed. I see no reason why s390 should behave differently from
the generic code, wrt to cleared_pxds setting in pxd_free_tlb().
So I guess this was an "off-by-one" mistake in commit 9de7d833e3708
("s390/tlb: Convert to generic mmu_gather"), since the other
pxd_free_tlb() functions also show similar puzzling behavior.
Not consistently off-by-one though, as pmd_free_tlb() seems
to behave correctly, setting tlb->cleared_puds = 1, similar to
generic code.
That was a very nice catch, Zhenyu, thanks for reporting!
We are not yet making use of the tlb->cleared_pxds for s390, but
we would certainly have stumbled over this if we ever tried.
Will send a patch to make s390 behave like generic code here.
Regards,
Gerald
_______________________________________________
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:[~2020-04-20 16:20 UTC|newest]
Thread overview: 16+ 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-28 4:30 ` Zhenyu Ye
2020-03-30 12:16 ` Peter Zijlstra
2020-03-30 12:16 ` Peter Zijlstra
2020-03-30 12:16 ` Peter Zijlstra
2020-03-31 8:15 ` Zhenyu Ye
2020-03-31 8:15 ` Zhenyu Ye
2020-03-31 8:15 ` Zhenyu Ye
2020-04-08 8:51 ` Christian Borntraeger
2020-04-08 8:51 ` Christian Borntraeger
2020-04-20 16:20 ` Gerald Schaefer [this message]
2020-04-20 16:20 ` Gerald Schaefer
2020-04-14 7:05 ` Christian Borntraeger
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=20200420182023.6b8e143a@thinkpad \
--to=gerald.schaefer@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=arm@kernel.org \
--cc=borntraeger@de.ibm.com \
--cc=bp@alien8.de \
--cc=gor@linux.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=luto@kernel.org \
--cc=maz@kernel.org \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--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 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.