On Mon, 2018-08-27 at 19:02 +1000, Nicholas Piggin wrote:
> > More tlbies ? With the cost of the broadasts on the fabric ? I don't
> > think so.. or I'm not understanding your point...
>
> More tlbies are no good, but there will be some places where it works
> out much better (and fewer tlbies).
On Mon, 2018-08-27 at 19:02 +1000, Nicholas Piggin wrote:
> > More tlbies ? With the cost of the broadasts on the fabric ? I don't
> > think so.. or I'm not understanding your point...
>
> More tlbies are no good, but there will be some places where it works
> out much better (and fewer tlbies).
On Thu, Aug 30, 2018 at 12:13:50AM +, Vineet Gupta wrote:
> On 08/27/2018 04:00 AM, Peter Zijlstra wrote:
> >
> > The one obvious thing SH and ARM want is a sensible default for
> > tlb_start_vma(). (also: https://lkml.org/lkml/2004/1/15/6 )
> >
> > The below make tlb_start_vma() default to
On Thu, Aug 30, 2018 at 12:13:50AM +, Vineet Gupta wrote:
> On 08/27/2018 04:00 AM, Peter Zijlstra wrote:
> >
> > The one obvious thing SH and ARM want is a sensible default for
> > tlb_start_vma(). (also: https://lkml.org/lkml/2004/1/15/6 )
> >
> > The below make tlb_start_vma() default to
On 08/27/2018 04:00 AM, Peter Zijlstra wrote:
>
> The one obvious thing SH and ARM want is a sensible default for
> tlb_start_vma(). (also: https://lkml.org/lkml/2004/1/15/6 )
>
> The below make tlb_start_vma() default to flush_cache_range(), which
> should be right and sufficient. The only
On 08/27/2018 04:00 AM, Peter Zijlstra wrote:
>
> The one obvious thing SH and ARM want is a sensible default for
> tlb_start_vma(). (also: https://lkml.org/lkml/2004/1/15/6 )
>
> The below make tlb_start_vma() default to flush_cache_range(), which
> should be right and sufficient. The only
On Mon, 27 Aug 2018 09:36:50 -0400
Rik van Riel wrote:
> On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote:
>
> > It could do that. It requires a tlbie that matches the page size,
> > so it means 3 sizes. I think possibly even that would be better
> > than current code, but we could do
On Mon, 27 Aug 2018 09:36:50 -0400
Rik van Riel wrote:
> On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote:
>
> > It could do that. It requires a tlbie that matches the page size,
> > so it means 3 sizes. I think possibly even that would be better
> > than current code, but we could do
On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote:
> It could do that. It requires a tlbie that matches the page size,
> so it means 3 sizes. I think possibly even that would be better
> than current code, but we could do better if we had a few specific
> fields in there.
Would it cause a
On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote:
> It could do that. It requires a tlbie that matches the page size,
> so it means 3 sizes. I think possibly even that would be better
> than current code, but we could do better if we had a few specific
> fields in there.
Would it cause a
I cannot speak to how widespread it has been adopted, but the linux
(kernel) package for version 4.17.17 has been successfully built and
installed for ia64 under Debian ports. There is clearly more work to
do to get ia64 rehabilitated, but there are over 10,000 packages
currently successfully
I cannot speak to how widespread it has been adopted, but the linux
(kernel) package for version 4.17.17 has been successfully built and
installed for ia64 under Debian ports. There is clearly more work to
do to get ia64 rehabilitated, but there are over 10,000 packages
currently successfully
On Mon, Aug 27, 2018 at 01:57:08AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> > sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> > arch/ia64' leaving us with s390.
>
> Is removing ia64 a serious plan?
I 'joked' about
On Mon, Aug 27, 2018 at 01:57:08AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> > sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> > arch/ia64' leaving us with s390.
>
> Is removing ia64 a serious plan?
I 'joked' about
On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> And there's only like 4 architectures that still have a custom
> mmu_gather:
>
> - sh
> - arm
> - ia64
> - s390
>
> sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> arch/ia64' leaving us with s390.
On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> And there's only like 4 architectures that still have a custom
> mmu_gather:
>
> - sh
> - arm
> - ia64
> - s390
>
> sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> arch/ia64' leaving us with s390.
On Mon, 27 Aug 2018 18:09:50 +1000
Benjamin Herrenschmidt wrote:
> On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote:
> > > Yes.. I see that. tlb_remove_check_page_size_change() really is a rather
> > > ugly thing, it can cause loads of TLB flushes. Do you really _have_ to
> > > do that?
On Mon, 27 Aug 2018 18:09:50 +1000
Benjamin Herrenschmidt wrote:
> On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote:
> > > Yes.. I see that. tlb_remove_check_page_size_change() really is a rather
> > > ugly thing, it can cause loads of TLB flushes. Do you really _have_ to
> > > do that?
On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> arch/ia64' leaving us with s390.
Is removing ia64 a serious plan? It is the cause for a fair share of
oddities in dma lang, and I did not have much luck
On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> arch/ia64' leaving us with s390.
Is removing ia64 a serious plan? It is the cause for a fair share of
oddities in dma lang, and I did not have much luck
On Mon, 27 Aug 2018 10:20:45 +0200
Peter Zijlstra wrote:
> On Mon, Aug 27, 2018 at 06:09:50PM +1000, Benjamin Herrenschmidt wrote:
>
> > Sadly our architecture requires a precise match between the page size
> > specified in the tlbie instruction and the entry in the TLB or it won't
> > be
On Mon, 27 Aug 2018 10:20:45 +0200
Peter Zijlstra wrote:
> On Mon, Aug 27, 2018 at 06:09:50PM +1000, Benjamin Herrenschmidt wrote:
>
> > Sadly our architecture requires a precise match between the page size
> > specified in the tlbie instruction and the entry in the TLB or it won't
> > be
On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote:
> > Yes.. I see that. tlb_remove_check_page_size_change() really is a rather
> > ugly thing, it can cause loads of TLB flushes. Do you really _have_ to
> > do that? The way ARM and x86 work is that using INVLPG in a 4K stride is
> > still
On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote:
> > Yes.. I see that. tlb_remove_check_page_size_change() really is a rather
> > ugly thing, it can cause loads of TLB flushes. Do you really _have_ to
> > do that? The way ARM and x86 work is that using INVLPG in a 4K stride is
> > still
On Mon, Aug 27, 2018 at 06:09:50PM +1000, Benjamin Herrenschmidt wrote:
> Sadly our architecture requires a precise match between the page size
> specified in the tlbie instruction and the entry in the TLB or it won't
> be flushed.
Argh.. OK I see. That is rather unfortunate and does seem to
On Mon, Aug 27, 2018 at 06:09:50PM +1000, Benjamin Herrenschmidt wrote:
> Sadly our architecture requires a precise match between the page size
> specified in the tlbie instruction and the entry in the TLB or it won't
> be flushed.
Argh.. OK I see. That is rather unfortunate and does seem to
On Mon, 27 Aug 2018 09:47:01 +0200
Peter Zijlstra wrote:
> On Mon, Aug 27, 2018 at 03:00:08PM +1000, Nicholas Piggin wrote:
> > On Fri, 24 Aug 2018 13:39:53 +0200
> > Peter Zijlstra wrote:
> > > On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:
>
> > > > Hurm.. look at
On Mon, 27 Aug 2018 09:47:01 +0200
Peter Zijlstra wrote:
> On Mon, Aug 27, 2018 at 03:00:08PM +1000, Nicholas Piggin wrote:
> > On Fri, 24 Aug 2018 13:39:53 +0200
> > Peter Zijlstra wrote:
> > > On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:
>
> > > > Hurm.. look at
On Mon, Aug 27, 2018 at 03:00:08PM +1000, Nicholas Piggin wrote:
> On Fri, 24 Aug 2018 13:39:53 +0200
> Peter Zijlstra wrote:
> > On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:
> > > Hurm.. look at commit:
> > >
> > > e77b0852b551 ("mm/mmu_gather: track page size with mmu
On Mon, Aug 27, 2018 at 03:00:08PM +1000, Nicholas Piggin wrote:
> On Fri, 24 Aug 2018 13:39:53 +0200
> Peter Zijlstra wrote:
> > On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:
> > > Hurm.. look at commit:
> > >
> > > e77b0852b551 ("mm/mmu_gather: track page size with mmu
On Fri, 24 Aug 2018 13:39:53 +0200
Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 24, 2018 at 10:47:17AM +0200, Peter Zijlstra wrote:
> > > On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> > > > The only problem with this
On Fri, 24 Aug 2018 13:39:53 +0200
Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 24, 2018 at 10:47:17AM +0200, Peter Zijlstra wrote:
> > > On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> > > > The only problem with this
On Fri, Aug 24, 2018 at 10:26:50AM -0700, Nadav Amit wrote:
> at 1:47 AM, Peter Zijlstra wrote:
>
> > On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> >> The only problem with this approach is that we've lost track of the granule
> >> size by the point we get to the tlb_flush(), so
On Fri, Aug 24, 2018 at 10:26:50AM -0700, Nadav Amit wrote:
> at 1:47 AM, Peter Zijlstra wrote:
>
> > On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> >> The only problem with this approach is that we've lost track of the granule
> >> size by the point we get to the tlb_flush(), so
at 1:47 AM, Peter Zijlstra wrote:
> On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
>> The only problem with this approach is that we've lost track of the granule
>> size by the point we get to the tlb_flush(), so we can't adjust the stride of
>> the TLB invalidations for huge
at 1:47 AM, Peter Zijlstra wrote:
> On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
>> The only problem with this approach is that we've lost track of the granule
>> size by the point we get to the tlb_flush(), so we can't adjust the stride of
>> the TLB invalidations for huge
Hi Peter,
On Fri, Aug 24, 2018 at 03:13:32PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 10:35:56AM +0200, Peter Zijlstra wrote:
>
> > Anyway, its sorted now; although I'd like to write me a fairly big
> > comment in asm-generic/tlb.h about things, before I forget again.
>
> How's
Hi Peter,
On Fri, Aug 24, 2018 at 03:13:32PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 10:35:56AM +0200, Peter Zijlstra wrote:
>
> > Anyway, its sorted now; although I'd like to write me a fairly big
> > comment in asm-generic/tlb.h about things, before I forget again.
>
> How's
On Fri, Aug 24, 2018 at 03:13:32PM +0200, Peter Zijlstra wrote:
> + * HAVE_RCU_TABLE_FREE
> + *
> + * This provides tlb_remove_table(), to be used instead of tlb_remove_page()
> + * for page directores (__p*_free_tlb()). This provides separate freeing of
> + * the page-table pages themselves
On Fri, Aug 24, 2018 at 03:13:32PM +0200, Peter Zijlstra wrote:
> + * HAVE_RCU_TABLE_FREE
> + *
> + * This provides tlb_remove_table(), to be used instead of tlb_remove_page()
> + * for page directores (__p*_free_tlb()). This provides separate freeing of
> + * the page-table pages themselves
On Fri, Aug 24, 2018 at 10:35:56AM +0200, Peter Zijlstra wrote:
> Anyway, its sorted now; although I'd like to write me a fairly big
> comment in asm-generic/tlb.h about things, before I forget again.
How's something like so? There's a little page_size thingy in this;
mostly because I couldn't
On Fri, Aug 24, 2018 at 10:35:56AM +0200, Peter Zijlstra wrote:
> Anyway, its sorted now; although I'd like to write me a fairly big
> comment in asm-generic/tlb.h about things, before I forget again.
How's something like so? There's a little page_size thingy in this;
mostly because I couldn't
On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 10:47:17AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> > > The only problem with this approach is that we've lost track of the
> > > granule
> > > size by
On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 24, 2018 at 10:47:17AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> > > The only problem with this approach is that we've lost track of the
> > > granule
> > > size by
On Fri, Aug 24, 2018 at 10:47:17AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> > The only problem with this approach is that we've lost track of the granule
> > size by the point we get to the tlb_flush(), so we can't adjust the stride
> > of
> >
On Fri, Aug 24, 2018 at 10:47:17AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> > The only problem with this approach is that we've lost track of the granule
> > size by the point we get to the tlb_flush(), so we can't adjust the stride
> > of
> >
On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> The only problem with this approach is that we've lost track of the granule
> size by the point we get to the tlb_flush(), so we can't adjust the stride of
> the TLB invalidations for huge mappings, which actually works nicely in the
>
On Thu, Aug 23, 2018 at 02:39:59PM +0100, Will Deacon wrote:
> The only problem with this approach is that we've lost track of the granule
> size by the point we get to the tlb_flush(), so we can't adjust the stride of
> the TLB invalidations for huge mappings, which actually works nicely in the
>
On Thu, Aug 23, 2018 at 02:54:20PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2018-08-22 at 20:59 -0700, Linus Torvalds wrote:
> > The problem is that x86 _used_ to do this all correctly long long ago.
> >
> > And then we switched over to the "generic" table flushing (which
> > harkens back
On Thu, Aug 23, 2018 at 02:54:20PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2018-08-22 at 20:59 -0700, Linus Torvalds wrote:
> > The problem is that x86 _used_ to do this all correctly long long ago.
> >
> > And then we switched over to the "generic" table flushing (which
> > harkens back
On Wed, Aug 22, 2018 at 05:55:27PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If
On Wed, Aug 22, 2018 at 05:55:27PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If
On Wed, Aug 22, 2018 at 10:11:41PM -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> wrote:
> >
> >
> > So we do need a different flush instruction for the page tables vs. the
> > normal TLB pages.
>
> Right. ARM wants it too. x86 is odd in that a regular
On Wed, Aug 22, 2018 at 10:11:41PM -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> wrote:
> >
> >
> > So we do need a different flush instruction for the page tables vs. the
> > normal TLB pages.
>
> Right. ARM wants it too. x86 is odd in that a regular
On Wed, 22 Aug 2018 17:30:15 +0200
Peter Zijlstra wrote:
> Jann reported that x86 was missing required TLB invalidates when he
> hit the !*batch slow path in tlb_remove_table().
>
> This is indeed the case; RCU_TABLE_FREE does not provide TLB (cache)
> invalidates, the PowerPC-hash where this
On Wed, 22 Aug 2018 17:30:15 +0200
Peter Zijlstra wrote:
> Jann reported that x86 was missing required TLB invalidates when he
> hit the !*batch slow path in tlb_remove_table().
>
> This is indeed the case; RCU_TABLE_FREE does not provide TLB (cache)
> invalidates, the PowerPC-hash where this
On Wed, 22 Aug 2018 22:20:32 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 10:11 PM Linus Torvalds
> wrote:
> >
> > So instead, when you get to the actual "tlb_flush(tlb)", you do
> > exactly that - flush the tlb. And the mmu_gather structure shows you
> > how much you need to flush. If
On Wed, 22 Aug 2018 22:20:32 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 10:11 PM Linus Torvalds
> wrote:
> >
> > So instead, when you get to the actual "tlb_flush(tlb)", you do
> > exactly that - flush the tlb. And the mmu_gather structure shows you
> > how much you need to flush. If
On Thu, 23 Aug 2018 15:21:30 +1000
Benjamin Herrenschmidt wrote:
> On Wed, 2018-08-22 at 22:11 -0700, Linus Torvalds wrote:
> > On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> > wrote:
> > >
> > >
> > > So we do need a different flush instruction for the page tables vs. the
> > >
On Thu, 23 Aug 2018 15:21:30 +1000
Benjamin Herrenschmidt wrote:
> On Wed, 2018-08-22 at 22:11 -0700, Linus Torvalds wrote:
> > On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> > wrote:
> > >
> > >
> > > So we do need a different flush instruction for the page tables vs. the
> > >
On Wed, 22 Aug 2018 22:03:40 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:33 PM Nicholas Piggin wrote:
> >
> > I think it was quite well understood and fixed here, a145abf12c9 but
> > again that was before I really started looking at it.
>
> You don't understand the problem.
More
On Wed, 22 Aug 2018 22:03:40 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:33 PM Nicholas Piggin wrote:
> >
> > I think it was quite well understood and fixed here, a145abf12c9 but
> > again that was before I really started looking at it.
>
> You don't understand the problem.
More
On Wed, 2018-08-22 at 22:11 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> wrote:
> >
> >
> > So we do need a different flush instruction for the page tables vs. the
> > normal TLB pages.
>
> Right. ARM wants it too. x86 is odd in that a regular
On Wed, 2018-08-22 at 22:11 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> wrote:
> >
> >
> > So we do need a different flush instruction for the page tables vs. the
> > normal TLB pages.
>
> Right. ARM wants it too. x86 is odd in that a regular
On Wed, Aug 22, 2018 at 10:11 PM Linus Torvalds
wrote:
>
> So instead, when you get to the actual "tlb_flush(tlb)", you do
> exactly that - flush the tlb. And the mmu_gather structure shows you
> how much you need to flush. If you see that "freed_tables" is set,
> then you know that you need to
On Wed, Aug 22, 2018 at 10:11 PM Linus Torvalds
wrote:
>
> So instead, when you get to the actual "tlb_flush(tlb)", you do
> exactly that - flush the tlb. And the mmu_gather structure shows you
> how much you need to flush. If you see that "freed_tables" is set,
> then you know that you need to
On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt wrote:
>
>
> So we do need a different flush instruction for the page tables vs. the
> normal TLB pages.
Right. ARM wants it too. x86 is odd in that a regular "invlpg" already
invalidates all the internal tlb cache nodes.
So the "new world
On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt wrote:
>
>
> So we do need a different flush instruction for the page tables vs. the
> normal TLB pages.
Right. ARM wants it too. x86 is odd in that a regular "invlpg" already
invalidates all the internal tlb cache nodes.
So the "new world
On Wed, Aug 22, 2018 at 9:33 PM Nicholas Piggin wrote:
>
> I think it was quite well understood and fixed here, a145abf12c9 but
> again that was before I really started looking at it.
You don't understand the problem.
All the x86 people thought WE ALREADY DID THAT.
Because we had done this all
On Wed, Aug 22, 2018 at 9:33 PM Nicholas Piggin wrote:
>
> I think it was quite well understood and fixed here, a145abf12c9 but
> again that was before I really started looking at it.
You don't understand the problem.
All the x86 people thought WE ALREADY DID THAT.
Because we had done this all
On Wed, 2018-08-22 at 20:59 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
> >
> > powerpc/radix has no such issue, it already does this tracking.
>
> Yeah, I now realize that this was why you wanted to add that hacky
> thing to the generic code, so that
On Wed, 2018-08-22 at 20:59 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
> >
> > powerpc/radix has no such issue, it already does this tracking.
>
> Yeah, I now realize that this was why you wanted to add that hacky
> thing to the generic code, so that
On Wed, 22 Aug 2018 20:59:46 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
> >
> > powerpc/radix has no such issue, it already does this tracking.
>
> Yeah, I now realize that this was why you wanted to add that hacky
> thing to the generic code, so
On Wed, 22 Aug 2018 20:59:46 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
> >
> > powerpc/radix has no such issue, it already does this tracking.
>
> Yeah, I now realize that this was why you wanted to add that hacky
> thing to the generic code, so
On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
>
> powerpc/radix has no such issue, it already does this tracking.
Yeah, I now realize that this was why you wanted to add that hacky
thing to the generic code, so that you can add the tlb_flush_pgtable()
call.
I thought it was because
On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
>
> powerpc/radix has no such issue, it already does this tracking.
Yeah, I now realize that this was why you wanted to add that hacky
thing to the generic code, so that you can add the tlb_flush_pgtable()
call.
I thought it was because
On Wed, 22 Aug 2018 17:55:27 +0200
Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If we
On Wed, 22 Aug 2018 17:55:27 +0200
Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If we
On Wed, Aug 22, 2018 at 8:46 AM Peter Zijlstra wrote:
>
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -180,6 +180,7 @@ config X86
> select HAVE_PERF_REGS
> select HAVE_PERF_USER_STACK_DUMP
> select HAVE_RCU_TABLE_FREE
> + select HAVE_RCU_TABLE_INVALIDATE
On Wed, Aug 22, 2018 at 8:46 AM Peter Zijlstra wrote:
>
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -180,6 +180,7 @@ config X86
> select HAVE_PERF_REGS
> select HAVE_PERF_USER_STACK_DUMP
> select HAVE_RCU_TABLE_FREE
> + select HAVE_RCU_TABLE_INVALIDATE
On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> ARM
> which later used this put an explicit TLB invalidate in their
> __p*_free_tlb() functions, and PowerPC-radix followed that example.
> +/*
> + * If we want tlb_remove_table() to imply TLB invalidates.
> + */
> +static inline
On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> ARM
> which later used this put an explicit TLB invalidate in their
> __p*_free_tlb() functions, and PowerPC-radix followed that example.
> +/*
> + * If we want tlb_remove_table() to imply TLB invalidates.
> + */
> +static inline
Jann reported that x86 was missing required TLB invalidates when he
hit the !*batch slow path in tlb_remove_table().
This is indeed the case; RCU_TABLE_FREE does not provide TLB (cache)
invalidates, the PowerPC-hash where this code originated and the
Sparc-hash where this was subsequently used
Jann reported that x86 was missing required TLB invalidates when he
hit the !*batch slow path in tlb_remove_table().
This is indeed the case; RCU_TABLE_FREE does not provide TLB (cache)
invalidates, the PowerPC-hash where this code originated and the
Sparc-hash where this was subsequently used
84 matches
Mail list logo
