Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-13 Thread demfloro
>I'm getting conflicts when trying to apply it ontop of rc4+tip/master but they >seem only contextual. Here's what applies: This patch helped with random kernel freezes during I/O on AMD FX-9590 CPU

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-13 Thread demfloro
>I'm getting conflicts when trying to apply it ontop of rc4+tip/master but they >seem only contextual. Here's what applies: This patch helped with random kernel freezes during I/O on AMD FX-9590 CPU

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-10 Thread Markus Trippelsdorf
On 2017.10.09 at 09:50 -0700, Andy Lutomirski wrote: > Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way > lazy: when running a kernel thread (including the idle thread), the > kernel keeps using the last user mm's page tables without attempting > to maintain user TLB coherence

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-10 Thread Markus Trippelsdorf
On 2017.10.09 at 09:50 -0700, Andy Lutomirski wrote: > Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way > lazy: when running a kernel thread (including the idle thread), the > kernel keeps using the last user mm's page tables without attempting > to maintain user TLB coherence

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Andy Lutomirski
On Mon, Oct 9, 2017 at 11:08 AM, Borislav Petkov wrote: > On Mon, Oct 09, 2017 at 10:50:34AM -0700, Andy Lutomirski wrote: >> The choices are somewhat lazy and not lazy at all. > > Yeah, you probably should explain those choices somewhere and what > exactly they mean. > >> The

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Andy Lutomirski
On Mon, Oct 9, 2017 at 11:08 AM, Borislav Petkov wrote: > On Mon, Oct 09, 2017 at 10:50:34AM -0700, Andy Lutomirski wrote: >> The choices are somewhat lazy and not lazy at all. > > Yeah, you probably should explain those choices somewhere and what > exactly they mean. > >> The degree of

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Borislav Petkov
On Mon, Oct 09, 2017 at 10:50:34AM -0700, Andy Lutomirski wrote: > The choices are somewhat lazy and not lazy at all. Yeah, you probably should explain those choices somewhere and what exactly they mean. > The degree of simplification I would get by removing it is basically > nil. The debugfs

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Borislav Petkov
On Mon, Oct 09, 2017 at 10:50:34AM -0700, Andy Lutomirski wrote: > The choices are somewhat lazy and not lazy at all. Yeah, you probably should explain those choices somewhere and what exactly they mean. > The degree of simplification I would get by removing it is basically > nil. The debugfs

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Andy Lutomirski
On Mon, Oct 9, 2017 at 10:36 AM, Borislav Petkov wrote: > On Mon, Oct 09, 2017 at 07:02:31PM +0200, Borislav Petkov wrote: >> From 29a6426c20f25b8df767356a04727cb113e8e784 Mon Sep 17 00:00:00 2001 >> From: Andy Lutomirski >> Date: Mon, 9 Oct 2017 09:50:49 -0700

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Andy Lutomirski
On Mon, Oct 9, 2017 at 10:36 AM, Borislav Petkov wrote: > On Mon, Oct 09, 2017 at 07:02:31PM +0200, Borislav Petkov wrote: >> From 29a6426c20f25b8df767356a04727cb113e8e784 Mon Sep 17 00:00:00 2001 >> From: Andy Lutomirski >> Date: Mon, 9 Oct 2017 09:50:49 -0700 >> Subject: [PATCH] x86/mm: Flush

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Borislav Petkov
On Mon, Oct 09, 2017 at 07:02:31PM +0200, Borislav Petkov wrote: > From 29a6426c20f25b8df767356a04727cb113e8e784 Mon Sep 17 00:00:00 2001 > From: Andy Lutomirski > Date: Mon, 9 Oct 2017 09:50:49 -0700 > Subject: [PATCH] x86/mm: Flush more aggressively in lazy TLB mode > > Since

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Borislav Petkov
On Mon, Oct 09, 2017 at 07:02:31PM +0200, Borislav Petkov wrote: > From 29a6426c20f25b8df767356a04727cb113e8e784 Mon Sep 17 00:00:00 2001 > From: Andy Lutomirski > Date: Mon, 9 Oct 2017 09:50:49 -0700 > Subject: [PATCH] x86/mm: Flush more aggressively in lazy TLB mode > > Since commit

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Borislav Petkov
+ Johannes Hirte. On Mon, Oct 09, 2017 at 09:50:49AM -0700, Andy Lutomirski wrote: > Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way ... > There are two optimizations we should probably do on top of this. > > - In lazy mode, we should switch to init_mm when entering a long

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Borislav Petkov
+ Johannes Hirte. On Mon, Oct 09, 2017 at 09:50:49AM -0700, Andy Lutomirski wrote: > Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way ... > There are two optimizations we should probably do on top of this. > > - In lazy mode, we should switch to init_mm when entering a long

[RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Andy Lutomirski
Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way lazy: when running a kernel thread (including the idle thread), the kernel keeps using the last user mm's page tables without attempting to maintain user TLB coherence at all. From a pure semantic perspective, this is fine --

[RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

2017-10-09 Thread Andy Lutomirski
Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way lazy: when running a kernel thread (including the idle thread), the kernel keeps using the last user mm's page tables without attempting to maintain user TLB coherence at all. From a pure semantic perspective, this is fine --