Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Thu, May 11, 2017 at 12:13 AM, Ingo Molnar wrote: > My personal favorite is double underscores prefix, i.e. 'void *__mm', which > would > clearly signal that this is something special. But this does not appear to > have > been picked up overly widely: Nice bikeshed! I'll

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Thu, May 11, 2017 at 12:13 AM, Ingo Molnar wrote: > My personal favorite is double underscores prefix, i.e. 'void *__mm', which > would > clearly signal that this is something special. But this does not appear to > have > been picked up overly widely: Nice bikeshed! I'll use it.

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

* Andy Lutomirski wrote: > On Wed, May 10, 2017 at 1:24 AM, Ingo Molnar wrote: > > > > * Thomas Gleixner wrote: > > > >> On Wed, 10 May 2017, Ingo Molnar wrote: > >> > > >> > * Thomas Gleixner wrote: > >> > > >> > >

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

* Andy Lutomirski wrote: > On Wed, May 10, 2017 at 1:24 AM, Ingo Molnar wrote: > > > > * Thomas Gleixner wrote: > > > >> On Wed, 10 May 2017, Ingo Molnar wrote: > >> > > >> > * Thomas Gleixner wrote: > >> > > >> > > On Sun, 7 May 2017, Andy Lutomirski wrote: > >> > > > /* context.lock is

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Wed, May 10, 2017 at 1:24 AM, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > >> On Wed, 10 May 2017, Ingo Molnar wrote: >> > >> > * Thomas Gleixner wrote: >> > >> > > On Sun, 7 May 2017, Andy Lutomirski wrote: >> > > > /*

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Wed, May 10, 2017 at 1:24 AM, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > >> On Wed, 10 May 2017, Ingo Molnar wrote: >> > >> > * Thomas Gleixner wrote: >> > >> > > On Sun, 7 May 2017, Andy Lutomirski wrote: >> > > > /* context.lock is held for us, so we don't need any locking. */ >> >

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

* Thomas Gleixner wrote: > On Wed, 10 May 2017, Ingo Molnar wrote: > > > > * Thomas Gleixner wrote: > > > > > On Sun, 7 May 2017, Andy Lutomirski wrote: > > > > /* context.lock is held for us, so we don't need any locking. */ > > > > static void

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

* Thomas Gleixner wrote: > On Wed, 10 May 2017, Ingo Molnar wrote: > > > > * Thomas Gleixner wrote: > > > > > On Sun, 7 May 2017, Andy Lutomirski wrote: > > > > /* context.lock is held for us, so we don't need any locking. */ > > > > static void flush_ldt(void *current_mm) > > > > { > > >

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Wed, 10 May 2017, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > > > On Sun, 7 May 2017, Andy Lutomirski wrote: > > > /* context.lock is held for us, so we don't need any locking. */ > > > static void flush_ldt(void *current_mm) > > > { > > > + struct mm_struct *mm

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Wed, 10 May 2017, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > > > On Sun, 7 May 2017, Andy Lutomirski wrote: > > > /* context.lock is held for us, so we don't need any locking. */ > > > static void flush_ldt(void *current_mm) > > > { > > > + struct mm_struct *mm = current_mm; > > >

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

* Thomas Gleixner wrote: > On Sun, 7 May 2017, Andy Lutomirski wrote: > > /* context.lock is held for us, so we don't need any locking. */ > > static void flush_ldt(void *current_mm) > > { > > + struct mm_struct *mm = current_mm; > > mm_context_t *pc; > > > > -

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

* Thomas Gleixner wrote: > On Sun, 7 May 2017, Andy Lutomirski wrote: > > /* context.lock is held for us, so we don't need any locking. */ > > static void flush_ldt(void *current_mm) > > { > > + struct mm_struct *mm = current_mm; > > mm_context_t *pc; > > > > - if

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Tue, May 9, 2017 at 1:41 PM, Thomas Gleixner wrote: > On Sun, 7 May 2017, Andy Lutomirski wrote: >> /* context.lock is held for us, so we don't need any locking. */ >> static void flush_ldt(void *current_mm) >> { >> + struct mm_struct *mm = current_mm; >>

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Tue, May 9, 2017 at 1:41 PM, Thomas Gleixner wrote: > On Sun, 7 May 2017, Andy Lutomirski wrote: >> /* context.lock is held for us, so we don't need any locking. */ >> static void flush_ldt(void *current_mm) >> { >> + struct mm_struct *mm = current_mm; >> mm_context_t *pc; >> >> -

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Sun, 7 May 2017, Andy Lutomirski wrote: > /* context.lock is held for us, so we don't need any locking. */ > static void flush_ldt(void *current_mm) > { > + struct mm_struct *mm = current_mm; > mm_context_t *pc; > > - if (current->active_mm != current_mm) > + if

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Sun, 7 May 2017, Andy Lutomirski wrote: > /* context.lock is held for us, so we don't need any locking. */ > static void flush_ldt(void *current_mm) > { > + struct mm_struct *mm = current_mm; > mm_context_t *pc; > > - if (current->active_mm != current_mm) > + if

[RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

Lazy TLB state is current managed in a rather baroque manner. AFAICT, there are three possible states: - Non-lazy. This means that we're running a user thread or a kernel thread that has called use_mm(). current->mm == current->active_mm == cpu_tlbstate.active_mm and

[RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

Lazy TLB state is current managed in a rather baroque manner. AFAICT, there are three possible states: - Non-lazy. This means that we're running a user thread or a kernel thread that has called use_mm(). current->mm == current->active_mm == cpu_tlbstate.active_mm and