[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YG6qCtRcz2ESUiFy@hirez.programming.kicks-ass.net>
Date: Thu, 8 Apr 2021 09:00:26 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Michel Lespinasse <michel@...pinasse.org>,
Linux-MM <linux-mm@...ck.org>,
Laurent Dufour <ldufour@...ux.ibm.com>,
Michal Hocko <mhocko@...e.com>,
Rik van Riel <riel@...riel.com>,
Paul McKenney <paulmck@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Joel Fernandes <joelaf@...gle.com>,
Rom Lemarchand <romlem@...gle.com>,
Linux-Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 24/37] mm: implement speculative handling in
__do_fault()
On Wed, Apr 07, 2021 at 10:27:12PM +0100, Matthew Wilcox wrote:
> Doing I/O without any lock held already works; it just uses the file
> refcount. It would be better to use a vma refcount, as I already said.
The original workload that I developed SPF for (waaaay back when) was
prefaulting a single huge vma. Using a vma refcount was a total loss
because it resulted in the same cacheline contention that down_read()
was having.
As such, I'm always incredibly sad to see mention of vma refcounts.
They're fundamentally not solving the problem :/
Powered by blists - more mailing lists