[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1001070934060.7821@localhost.localdomain>
Date: Thu, 7 Jan 2010 09:36:17 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
cc: Christoph Lameter <cl@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"minchan.kim@...il.com" <minchan.kim@...il.com>,
"hugh.dickins" <hugh.dickins@...cali.co.uk>,
Nick Piggin <nickpiggin@...oo.com.au>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault()
On Thu, 7 Jan 2010, Peter Zijlstra wrote:
>
> Right, supposing we can make this speculative fault stuff work, then we
> can basically reduce the mmap_sem usage in fault to:
>
> - allocating new page tables
> - extending the growable vmas
>
> And do everything else without holding it, including zeroing and IO.
Well, I have yet to hear a realistic scenario of _how_ to do it all
speculatively in the first place, at least not without horribly subtle
complexity issues. So I'd really rather see how far we can possibly get by
just improving mmap_sem.
Linus
--
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