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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 CDE7FC4361B for ; Wed, 16 Dec 2020 18:41:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 70BF3233F6 for ; Wed, 16 Dec 2020 18:41:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 70BF3233F6 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 AE1346B005D; Wed, 16 Dec 2020 13:41:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A92236B0068; Wed, 16 Dec 2020 13:41:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A79A6B006C; Wed, 16 Dec 2020 13:41:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 818E76B005D for ; Wed, 16 Dec 2020 13:41:58 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 42655181AEF00 for ; Wed, 16 Dec 2020 18:41:58 +0000 (UTC) X-FDA: 77600014716.23.turn32_13136782742e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 1E3E737604 for ; Wed, 16 Dec 2020 18:41:58 +0000 (UTC) X-HE-Tag: turn32_13136782742e X-Filterd-Recvd-Size: 5860 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Wed, 16 Dec 2020 18:41:57 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id a12so50926408lfl.6 for ; Wed, 16 Dec 2020 10:41:57 -0800 (PST) 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=YCn/jCPPDZXlf9ePKIfj8E1795/GsgQ/JdHgm4LtjQA=; b=HIyDgDllo8p73lQ4EedSHwaWwaKKnRLXD1OwFgDxoxIQ/SZX+nE8RY1+JFfOMMNOfE pT2IwSFXNJFAjZI13/AKsRY8MFWCn7BCOxnwBrXezhQDGQjEmdbhveZeljr1A0JfDmgQ CZuKFp6T5JFWi+Qfv7n8eEGxFkOSFelNXYySU= 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=YCn/jCPPDZXlf9ePKIfj8E1795/GsgQ/JdHgm4LtjQA=; b=DzWj1ZWbsCDw4LoTl3IQ9epcacjwFxyxTnR6Bve0d31XoarVH81ntkMBha8RM4aaZn m/89Q8kNgfFqpEml6InLijpr+1vJM5OEbTSFkArZX9UQX1GBlRgznvIqAE+G5O2vuQcD DUzYwVZZpPM8o2B+E/5mV5eQgNYpJu/bIFyWmX6OO7w9U33OIbJyzDWXBK/TArWUkV7o 5+NF1OY0yP7WibebH6aqVgrpC/CJ1YfyQXi2EyqtUL02fVu+PT4UqLEyIAJgqQu6upfe to3oiITT8girK4ofOfGqCQ57fkrMWtVd6y8kNYUXfoq/PeWseu8VHnHVk4Gk2Xmg3wEv RT3w== X-Gm-Message-State: AOAM531kAYVQUs6lNrBss43p44YYPc5o5UFl4vpeZXGcm9F/kRp8l5dx hOPzhChM0kY4gXqQLiYjdr2UlL3S0eKX6w== X-Google-Smtp-Source: ABdhPJw9h1GIHK2E9Hh9V+pjloXeh9wTe2C3jnjz0QdEWII6c6CXtk+VKRibrjCYl5ZYQMu44Em0ig== X-Received: by 2002:a2e:8557:: with SMTP id u23mr15182482ljj.287.1608144115183; Wed, 16 Dec 2020 10:41:55 -0800 (PST) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id l8sm317931lfk.120.2020.12.16.10.41.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Dec 2020 10:41:53 -0800 (PST) Received: by mail-lf1-f51.google.com with SMTP id y19so50838349lfa.13 for ; Wed, 16 Dec 2020 10:41:53 -0800 (PST) X-Received: by 2002:a05:6512:789:: with SMTP id x9mr8684864lfr.487.1608144113096; Wed, 16 Dec 2020 10:41:53 -0800 (PST) MIME-Version: 1.0 References: <20201209163950.8494-1-will@kernel.org> <20201209163950.8494-2-will@kernel.org> <20201209184049.GA8778@willie-the-truck> <20201210150828.4b7pg5lx666r7l2u@black.fi.intel.com> <20201214160724.ewhjqoi32chheone@box> <20201216170703.o5lpsnjfmoj7f3ml@box> In-Reply-To: <20201216170703.o5lpsnjfmoj7f3ml@box> From: Linus Torvalds Date: Wed, 16 Dec 2020 10:41:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting To: "Kirill A. Shutemov" Cc: Matthew Wilcox , "Kirill A. Shutemov" , Will Deacon , Linux Kernel Mailing List , Linux-MM , Linux ARM , Catalin Marinas , Jan Kara , Minchan Kim , Andrew Morton , Vinayak Menon , Android Kernel Team 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 Wed, Dec 16, 2020 at 9:07 AM Kirill A. Shutemov wrote: > > If this looks fine, I'll submit a proper patch. That patch looks good to me. It would be good if somebody else looked it through - maybe I like it just because I got to pee in the snow and make my mark. But i think that filemap_map_pages() now looks a lot more understandable, and having that pte_offset_map_lock() outside the loop should be good. In particular, it will make it much easier to then make arguments about things like - increase the page mapping count - check that the page is not locked - check that the page still has a mapping we can say "we know we hold the page table lock, and we increased the page mapping count, and we saw that the page still had a mapping and was not locked after that". And that means that with some trivial memory ordering rules, we can know that any concurrent "truncate()" that got the page lock after we checked it, will get held up at if (page_mapped(page)) { unsigned int nr = thp_nr_pages(page); unmap_mapping_pages(mapping, page->index, nr, false); } in truncate_cleanup_page(), and that means that we can safely map the page _without_ ever actually even doing a "trylock_page()" at all. Before this patch of yours, that logic would have been broken, because the page table lock wasn't actually held for the whole first iteration of that loop in filemap_map_pages(). And getting rid of the trylock_page() in that path gets rid of _the_ major page lock case for at least one class of loads. So I like the patch. But I would _really_ like for somebody else to look at it, and look at my thinking above. Because maybe I'm missing something. Linus