From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BBD6C4360C for ; Fri, 27 Sep 2019 16:40:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0016621841 for ; Fri, 27 Sep 2019 16:40:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="IbzOc3i8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0016621841 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6E82A8E0006; Fri, 27 Sep 2019 12:40:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 671E18E0001; Fri, 27 Sep 2019 12:40:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 537988E0006; Fri, 27 Sep 2019 12:40:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0107.hostedemail.com [216.40.44.107]) by kanga.kvack.org (Postfix) with ESMTP id 2C24E8E0001 for ; Fri, 27 Sep 2019 12:40:10 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id CE69E2C1F for ; Fri, 27 Sep 2019 16:40:09 +0000 (UTC) X-FDA: 75981262938.03.uncle89_3b8b1d95fb15a X-HE-Tag: uncle89_3b8b1d95fb15a X-Filterd-Recvd-Size: 5938 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Fri, 27 Sep 2019 16:40:09 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id f5so3127474ljg.8 for ; Fri, 27 Sep 2019 09:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xikpq9YYpaESAspYkHi86qdMdW/0HQNg7LvP7+WL5BI=; b=IbzOc3i8Qh0m8AF1EsRhezxjzpKCXsufVYfdSoXZLVLOVoGXeqKHkqV7wBluqDOwbT MCp9ANQ3eaGMUd8ZEHipocDweq22Nvp//cUG/Wnjk17KiGBd1UpAGJPuLeiMx8y+mZqx jxeglbySlcyzMuq1nYuuyMtVfExCtAU9niysk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xikpq9YYpaESAspYkHi86qdMdW/0HQNg7LvP7+WL5BI=; b=ekyEzPSNxEi+4OiAzk8K54cocySV59UYirJU6tY5FOWueFiwvGhD7fCb26nfoNA5L8 nNxPSSiVhV3f8fdlj9HrlrPJJEhMVRAh8/dAL6/tK9e7t2FLN8CK77dy+pkHkIaXFqKc m2L9kXu+WBHhqxPfLa1Eo1q4F6BW+m0Hia3x5wXk3WVg1tiFMNGBDBcIB2m/fdHVoURA tJtYXU8eNLHsgl44vG193K/ytU5B6OAYtGUyp5h0P80J6vlSQuGTsygz7vbr56WpOOkZ 2Uzh0iVkKow2U+RmSv2l3cXne4RRAX2TixhYEQoE4brimi0tPwY5XgRaKoj9jcc4x+4Z FiCQ== X-Gm-Message-State: APjAAAVL0rE5j80uTxORRiMyKeGHt2HcllEofC5dBhGErQBU9GjT9c/O 4ByMJjI8cuPXKcuJK0TMJjs0orp+ViM= X-Google-Smtp-Source: APXvYqxb3subtdtYQTvcsvvf3pBakEhz9Ou2Oj39X3fwz1VN4sPyO+h1v13vC+yI7oZdo7/pLrOiKQ== X-Received: by 2002:a2e:5d98:: with SMTP id v24mr3763657lje.56.1569602406365; Fri, 27 Sep 2019 09:40:06 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id m17sm687547lje.0.2019.09.27.09.40.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Sep 2019 09:40:05 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id q11so2383945lfc.11 for ; Fri, 27 Sep 2019 09:40:04 -0700 (PDT) X-Received: by 2002:a19:f204:: with SMTP id q4mr3381847lfh.29.1569602404666; Fri, 27 Sep 2019 09:40:04 -0700 (PDT) MIME-Version: 1.0 References: <20190926115548.44000-1-thomas_os@shipmail.org> <20190926115548.44000-2-thomas_os@shipmail.org> <85e31bcf-d3c8-2fcf-e659-2c9f82ebedc7@shipmail.org> <20190927121754.kn46qh2crvsnw5z2@box> In-Reply-To: <20190927121754.kn46qh2crvsnw5z2@box> From: Linus Torvalds Date: Fri, 27 Sep 2019 09:39:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges To: "Kirill A. Shutemov" Cc: =?UTF-8?Q?Thomas_Hellstr=C3=B6m_=28VMware=29?= , Linux Kernel Mailing List , dri-devel , Linux-MM , Andrew Morton , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Sep 27, 2019 at 5:17 AM Kirill A. Shutemov wrote: > > > Call it "walk_page_mapping()". And talk extensively about how the > > locking differs a lot from the usual "walk_page_vma()" things. > > Walking mappings of a page is what rmap does. This code thas to be > integrated there. Well, that's very questionable. The rmap code mainly does the "page -> virtual" mapping. One page at a time. The page walker code does the "virtual -> pte" mapping. Always a whole range at a time. The new code wants a combination of both. It very much is about walking ranges - as in mm/pagewalk.c. It's just that it walks potentially multiple ranges, based on where the address space is mapped. I think it has way more commonalities with the page walking code than it has with the rmap code. But yes, there is some of that "look up mappings based on address space" in there too, but it's the least part of it And as Thomas pointed out, it also has commonalities with unmap_mapping_pages() in mm/memory.c. In many ways that part is the closest. I'd say that from a code sharing standpoint, mm/rmap.c is absolutely the wrong place. It's the furthest away from what Thomas wants to do. The mm/pagewalk.c code has the most actual code that could be shared, and the addition would be smallest there. And conceptually the closest analogue in terms of what it _does_ is unmap_mapping_range() in mm/memory.c, but I see no room for sharing actual code there unless we completely change how we do zap_page_range() and add a lot of configurability there (which we don't want, because page table teardown at exit is really a pretty critical operation - I commonly see copy_page_range() and zap_page_range() on profiles if you have things like script-heavyu traditional UNIX loads). So I think conceptually, mm/memory.c and unmap_mapping_range() is closest but I don't think it's practical to share code. And between mm/pagewalk.c and mm/rmap.c, I think the page walking has way more of actual practical code sharing, and is also conceptually closer because most of the code is about walking a range, not looking up the mapping of one page. Linus