[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141021081159.GK23531@worktop.programming.kicks-ass.net>
Date: Tue, 21 Oct 2014 10:11:59 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: torvalds@...ux-foundation.org, paulmck@...ux.vnet.ibm.com,
tglx@...utronix.de, akpm@...ux-foundation.org, riel@...hat.com,
mgorman@...e.de, oleg@...hat.com, mingo@...hat.com,
minchan@...nel.org, kamezawa.hiroyu@...fujitsu.com,
viro@...iv.linux.org.uk, laijs@...fujitsu.com, dave@...olabs.net,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC][PATCH 0/6] Another go at speculative page faults
On Mon, Oct 20, 2014 at 05:07:02PM -0700, Andy Lutomirski wrote:
> On 10/20/2014 02:56 PM, Peter Zijlstra wrote:
> > Hi,
> >
> > I figured I'd give my 2010 speculative fault series another spin:
> >
> > https://lkml.org/lkml/2010/1/4/257
> >
> > Since then I think many of the outstanding issues have changed sufficiently to
> > warrant another go. In particular Al Viro's delayed fput seems to have made it
> > entirely 'normal' to delay fput(). Lai Jiangshan's SRCU rewrite provided us
> > with call_srcu() and my preemptible mmu_gather removed the TLB flushes from
> > under the PTL.
> >
> > The code needs way more attention but builds a kernel and runs the
> > micro-benchmark so I figured I'd post it before sinking more time into it.
> >
> > I realize the micro-bench is about as good as it gets for this series and not
> > very realistic otherwise, but I think it does show the potential benefit the
> > approach has.
>
> Does this mean that an entire fault can complete without ever taking
> mmap_sem at all? If so, that's a *huge* win.
Yep.
> I'm a bit concerned about drivers that assume that the vma is unchanged
> during .fault processing. In particular, is there a race between .close
> and .fault? Would it make sense to add a per-vma rw lock and hold it
> during vma modification and .fault calls?
VMA granularity contention would be about as bad as mmap_sem for many
workloads. But yes, that is one of the things we need to look at, I was
_hoping_ that holding the file open would sort most these problems, but
I'm sure there plenty 'interesting' cruft left.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists