From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by kanga.kvack.org (Postfix) with ESMTP id 189B66B0072 for ; Thu, 5 Mar 2015 12:39:50 -0500 (EST) Received: by igkb16 with SMTP id b16so47838046igk.1 for ; Thu, 05 Mar 2015 09:39:50 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com. [2607:f8b0:4001:c03::233]) by mx.google.com with ESMTPS id n14si19761095igx.1.2015.03.05.09.39.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 09:39:49 -0800 (PST) Received: by iebtr6 with SMTP id tr6so5333990ieb.4 for ; Thu, 05 Mar 2015 09:39:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1425575884-2574-20-git-send-email-aarcange@redhat.com> References: <1425575884-2574-1-git-send-email-aarcange@redhat.com> <1425575884-2574-20-git-send-email-aarcange@redhat.com> Date: Thu, 5 Mar 2015 09:39:48 -0800 Message-ID: Subject: Re: [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Andrea Arcangeli Cc: qemu-devel@nongnu.org, KVM list , Linux Kernel Mailing List , linux-mm , Linux API , Android Kernel Team , "Kirill A. Shutemov" , Pavel Emelyanov , Sanidhya Kashyap , zhang.zhanghailiang@huawei.com, Andres Lagar-Cavilla , Dave Hansen , Paolo Bonzini , Rik van Riel , Mel Gorman , Andy Lutomirski , Andrew Morton , Sasha Levin , Hugh Dickins , Peter Feiner , "Dr. David Alan Gilbert" , Christopher Covington , Johannes Weiner , Robert Love , Dmitry Adamushko , Neil Brown , Mike Hommey , Taras Glek , Jan Kara , KOSAKI Motohiro , Michel Lespinasse , Minchan Kim , Keith Packard , "Huangpeng (Peter)" , Anthony Liguori , Stefan Hajnoczi , Wenchao Xia , Andrew Jones , Juan Quintela On Thu, Mar 5, 2015 at 9:18 AM, Andrea Arcangeli wrote: > remap_pages is the lowlevel mm helper needed to implement > UFFDIO_REMAP. This function is nasty nasty nasty. Is this really worth it? On real loads? That people are expected to use? Considering how we just got rid of one special magic VM remapping thing that nobody actually used, I'd really hate to add a new one. The fact is, almost nobody ever uses anything that isn't standard POSIX. There are no apps, and even for specialized things like virtualization hypervisors this kind of thing is often simply not worth it. Quite frankly, *if* we ever merge userfaultfd, I would *strongly* argue for not merging the remap parts. I just don't see the point. It doesn't seem to add anything that is semantically very important - it's *potentially* a faster copy, but even that is (a) questionable in the first place and (b) unclear why anybody would ever care about performance of infrastructure that nobody actually uses today, and future use isn't even clear or shown to be particualrly performance-sensitive. So basically I'd like to see better documentation, a few real use cases (and by real I very much do *not* mean "you can use it for this", but actual patches to actual projects that matter and that are expected to care and merge them), and a simplified series that doesn't do the remap thing. Because *every* time we add a new clever interface, we end up with approximately zero users and just pain down the line. Examples: splice, mremap, yadda yadda. 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