From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by kanga.kvack.org (Postfix) with ESMTP id CE3E76B0035 for ; Wed, 7 May 2014 03:20:17 -0400 (EDT) Received: by mail-qg0-f49.google.com with SMTP id a108so619896qge.22 for ; Wed, 07 May 2014 00:20:17 -0700 (PDT) Received: from gate.crashing.org (gate.crashing.org. [63.228.1.57]) by mx.google.com with ESMTPS id 105si6350199qgw.110.2014.05.07.00.20.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 May 2014 00:20:16 -0700 (PDT) Message-ID: <1399447116.4161.36.camel@pasglop> Subject: Re: [RFC] Heterogeneous memory management (mirror process address space on a device mmu). From: Benjamin Herrenschmidt Date: Wed, 07 May 2014 17:18:36 +1000 In-Reply-To: References: <1399038730-25641-1-git-send-email-j.glisse@gmail.com> <20140506102925.GD11096@twins.programming.kicks-ass.net> <20140506150014.GA6731@gmail.com> <20140506153315.GB6731@gmail.com> <20140506161836.GC6731@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Jerome Glisse , Peter Zijlstra , linux-mm , Linux Kernel Mailing List , linux-fsdevel , Mel Gorman , "H. Peter Anvin" , Andrew Morton , Linda Wang , Kevin E Martin , Jerome Glisse , Andrea Arcangeli , Johannes Weiner , Larry Woodman , Rik van Riel , Dave Airlie , Jeff Law , Brendan Conoboy , Joe Donohue , Duncan Poole , Sherry Cheung , Subhash Gutti , John Hubbard , Mark Hairgrove , Lucien Dunning , Cameron Buschardt , Arvind Gopalakrishnan , Haggai Eran , Or Gerlitz , Sagi Grimberg , Shachar Raindel , Liran Liss , Roland Dreier , "Sander, Ben" , "Stoner, Greg" , "Bridgman, John" , "Mantor, Michael" , "Blinzer, Paul" , "Morichetti, Laurent" , "Deucher, Alexander" , "Gabbay, Oded" , Davidlohr Bueso On Tue, 2014-05-06 at 09:32 -0700, Linus Torvalds wrote: > and what I think a GPU flush has to do is to do the actual flushes > when asked to (because that's what it will need to do to work with a > real TLB eventually), but if there's some crazy asynchronous > acknowledge thing from hardware, it's possible to perhaps wait for > that in the final phase (*before* we free the pages we gathered). Hrm, difficult. We have some pretty strong assumptions that ptep_clear_flush() is fully synchronous as far as I can tell... ie, your trick would work for the unmap case but everything else is still problematic. Ben. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org