>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
>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
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
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
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
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
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
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
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
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
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
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
+ 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
+ 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
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 --
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 --
16 matches
Mail list logo