[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 Jul 2018 01:25:38 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: Rik van Riel <riel@...riel.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
"kirill.shutemov" <kirill.shutemov@...ux.intel.com>,
Minchan Kim <minchan@...nel.org>,
Mel Gorman <mgorman@...hsingularity.net>,
kernel-team <kernel-team@...com>
Subject: Re: mm,tlb: revert 4647706ebeee?
On Fri, 06 Jul 2018 13:03:55 -0400
Rik van Riel <riel@...riel.com> wrote:
> Hello,
>
> It looks like last summer, there were 2 sets of patches
> in flight to fix the issue of simultaneous mprotect/madvise
> calls unmapping PTEs, and some pages not being flushed from
> the TLB before returning to userspace.
>
> Minchan posted these patches:
> 56236a59556c ("mm: refactor TLB gathering API")
> 99baac21e458 ("mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem")
>
> Around the same time, Mel posted:
> 4647706ebeee ("mm: always flush VMA ranges affected by zap_page_range")
>
> They both appear to solve the same bug.
>
> Only one of the two solutions is needed.
>
> However, 4647706ebeee appears to introduce extra TLB
> flushes - one per VMA, instead of one over the entire
> range unmapped, and also extra flushes when there are
> no simultaneous unmappers of the same mm.
>
> For that reason, it seems like we should revert
> 4647706ebeee and keep only Minchan's solution in
> the kernel.
>
> Am I overlooking any reason why we should not revert
> 4647706ebeee?
Yes I think so. Discussed here recently:
https://marc.info/?l=linux-mm&m=152878780528037&w=2
Actually we realized that powerpc does not implement the mmu
gather flushing quite right so it needs a fix before this
revert. But I propose the revert for next merge window.
Thanks,
Nick
Powered by blists - more mailing lists