Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1681387 > unrolled thread

Re: [PATCH v4 00/10] PCID and improved laziness

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 00/10] PCID and improved laziness Ingo Molnar <mingo@kernel.org> - 2017-07-05 11:00 +0200
    Re: [PATCH v4 00/10] PCID and improved laziness Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-05 19:00 +0200
    Re: [PATCH v4 00/10] PCID and improved laziness Mel Gorman <mgorman@suse.de> - 2017-07-17 12:00 +0200
      Re: [PATCH v4 00/10] PCID and improved laziness Ingo Molnar <mingo@kernel.org> - 2017-07-17 17:10 +0200
        Re: [PATCH v4 00/10] PCID and improved laziness Mel Gorman <mgorman@suse.de> - 2017-07-17 18:00 +0200

#1681387 — Re: [PATCH v4 00/10] PCID and improved laziness

* Andy Lutomirski <luto@kernel.org> wrote:

> *** Ingo, even if this misses 4.13, please apply the first patch before
> *** the merge window.

> Andy Lutomirski (10):
>   x86/mm: Don't reenter flush_tlb_func_common()
>   x86/mm: Delete a big outdated comment about TLB flushing
>   x86/mm: Give each mm TLB flush generation a unique ID
>   x86/mm: Track the TLB's tlb_gen and update the flushing algorithm
>   x86/mm: Rework lazy TLB mode and TLB freshness tracking
>   x86/mm: Stop calling leave_mm() in idle code
>   x86/mm: Disable PCID on 32-bit kernels
>   x86/mm: Add nopcid to turn off PCID
>   x86/mm: Enable CR4.PCIDE on supported systems
>   x86/mm: Try to preserve old TLB entries using PCID

So this series is really nice, and the first two patches are already upstream, and 
I've just applied all but the final patch to tip:x86/mm (out of caution - I'm a wimp).

That should already offer some improvements and enables the CR4 bit - but doesn't 
actually use the PCID hardware yet.

I'll push it all out when it passes testing.

If it's all super stable I plan to tempt Linus with a late merge window pull 
request for all these preparatory patches. (Unless he objects that is. Hint, hint.)

Any objections?

Thanks,

	Ingo

[toc] | [next] | [standalone]

#1681659

On Wed, Jul 5, 2017 at 1:56 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> If it's all super stable I plan to tempt Linus with a late merge window pull
> request for all these preparatory patches. (Unless he objects that is. Hint, hint.)

I don't think I'll object. At some point the best testing is "lots of users".

TLB issues are a bitch to debug, but at the same time this is clearly
a "..but at some point we need to bite the bullet" case. I doubt the
series is going to get a lot better.

But yes, please do give it as much testing as humanly possible even
without the wider coverage by random people.

               Linus

[toc] | [prev] | [next] | [standalone]

#1688835

On Wed, Jul 05, 2017 at 10:56:57AM +0200, Ingo Molnar wrote:
> 
> * Andy Lutomirski <luto@kernel.org> wrote:
> 
> > *** Ingo, even if this misses 4.13, please apply the first patch before
> > *** the merge window.
> 
> > Andy Lutomirski (10):
> >   x86/mm: Don't reenter flush_tlb_func_common()
> >   x86/mm: Delete a big outdated comment about TLB flushing
> >   x86/mm: Give each mm TLB flush generation a unique ID
> >   x86/mm: Track the TLB's tlb_gen and update the flushing algorithm
> >   x86/mm: Rework lazy TLB mode and TLB freshness tracking
> >   x86/mm: Stop calling leave_mm() in idle code
> >   x86/mm: Disable PCID on 32-bit kernels
> >   x86/mm: Add nopcid to turn off PCID
> >   x86/mm: Enable CR4.PCIDE on supported systems
> >   x86/mm: Try to preserve old TLB entries using PCID
> 
> So this series is really nice, and the first two patches are already upstream, and 
> I've just applied all but the final patch to tip:x86/mm (out of caution - I'm a wimp).
> 
> That should already offer some improvements and enables the CR4 bit - but doesn't 
> actually use the PCID hardware yet.
> 
> I'll push it all out when it passes testing.
> 
> If it's all super stable I plan to tempt Linus with a late merge window pull 
> request for all these preparatory patches. (Unless he objects that is. Hint, hint.)
> 
> Any objections?
> 

What was the final verdict here? I have a patch ready that should be layered
on top which will need a backport. PCID support does not appear to have
made it in this merge window so I'm wondering if I should send the patch
as-is for placement on top of Andy's work or go with the backport and
apply a follow-on patch after Andy's work gets merged.

Thanks.

-- 
Mel Gorman
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1689165

* Mel Gorman <mgorman@suse.de> wrote:

> On Wed, Jul 05, 2017 at 10:56:57AM +0200, Ingo Molnar wrote:
> > 
> > * Andy Lutomirski <luto@kernel.org> wrote:
> > 
> > > *** Ingo, even if this misses 4.13, please apply the first patch before
> > > *** the merge window.
> > 
> > > Andy Lutomirski (10):
> > >   x86/mm: Don't reenter flush_tlb_func_common()
> > >   x86/mm: Delete a big outdated comment about TLB flushing
> > >   x86/mm: Give each mm TLB flush generation a unique ID
> > >   x86/mm: Track the TLB's tlb_gen and update the flushing algorithm
> > >   x86/mm: Rework lazy TLB mode and TLB freshness tracking
> > >   x86/mm: Stop calling leave_mm() in idle code
> > >   x86/mm: Disable PCID on 32-bit kernels
> > >   x86/mm: Add nopcid to turn off PCID
> > >   x86/mm: Enable CR4.PCIDE on supported systems
> > >   x86/mm: Try to preserve old TLB entries using PCID
> > 
> > So this series is really nice, and the first two patches are already upstream, and 
> > I've just applied all but the final patch to tip:x86/mm (out of caution - I'm a wimp).
> > 
> > That should already offer some improvements and enables the CR4 bit - but doesn't 
> > actually use the PCID hardware yet.
> > 
> > I'll push it all out when it passes testing.
> > 
> > If it's all super stable I plan to tempt Linus with a late merge window pull 
> > request for all these preparatory patches. (Unless he objects that is. Hint, hint.)
> > 
> > Any objections?
> > 
> 
> What was the final verdict here? I have a patch ready that should be layered
> on top which will need a backport. PCID support does not appear to have
> made it in this merge window so I'm wondering if I should send the patch
> as-is for placement on top of Andy's work or go with the backport and
> apply a follow-on patch after Andy's work gets merged.

It's en route for v4.14 - it narrowly missed v4.13.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1689184

On Mon, Jul 17, 2017 at 05:06:25PM +0200, Ingo Molnar wrote:
> > > I'll push it all out when it passes testing.
> > > 
> > > If it's all super stable I plan to tempt Linus with a late merge window pull 
> > > request for all these preparatory patches. (Unless he objects that is. Hint, hint.)
> > > 
> > > Any objections?
> > > 
> > 
> > What was the final verdict here? I have a patch ready that should be layered
> > on top which will need a backport. PCID support does not appear to have
> > made it in this merge window so I'm wondering if I should send the patch
> > as-is for placement on top of Andy's work or go with the backport and
> > apply a follow-on patch after Andy's work gets merged.
> 
> It's en route for v4.14 - it narrowly missed v4.13.
> 

Grand. I sent out a version that doesn't depend on Andy's work to Andrew
as it's purely a mm patch. If that passes inspection then I'll send a
follow-on patch to apply on top of the PCID work.

Thanks Ingo.

-- 
Mel Gorman
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web