From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by kanga.kvack.org (Postfix) with ESMTP id E3BA76B0037 for ; Tue, 6 May 2014 14:22:49 -0400 (EDT) Received: by mail-ve0-f171.google.com with SMTP id oz11so3475009veb.30 for ; Tue, 06 May 2014 11:22:49 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [2607:f8b0:400c:c03::22b]) by mx.google.com with ESMTPS id d12si2466019vco.83.2014.05.06.11.22.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 11:22:49 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lc6so1479879vcb.16 for ; Tue, 06 May 2014 11:22:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140506181308.GG6731@gmail.com> References: <20140506102925.GD11096@twins.programming.kicks-ass.net> <20140506150014.GA6731@gmail.com> <20140506153315.GB6731@gmail.com> <20140506161836.GC6731@gmail.com> <20140506172853.GF6731@gmail.com> <20140506181308.GG6731@gmail.com> Date: Tue, 6 May 2014 11:22:48 -0700 Message-ID: Subject: Re: [RFC] Heterogeneous memory management (mirror process address space on a device mmu). From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Jerome Glisse Cc: 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, May 6, 2014 at 11:13 AM, Jerome Glisse wrote: > > I could grow the radix function to return some bool to avoid looping over for > case where there is no special entry. .. or even just a bool (or counter) associated with the mapping to mark whether any special entries exist at all. Also, the code to turn special entries is duplicated over and over again, usually together with a "FIXME - what about migration failure", so it would make sense to do that as it's own function. But conceptually I don't hate it. I didn't much like having random hmm_pagecache_migrate() calls in core vm code, and code like this + hmm_pagecache_migrate(mapping, swap); + spd.pages[page_nr] = find_get_page(mapping, index + page_nr); looks fundamentally racy, and in other places you seemed to assume that all exceptional entries are always about hmm, which looked questionable. But those are details. The concept of putting a special swap entry in the mapping radix trees I don't necessarily find objectionable per se. Linus -- 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