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 25440C4361B for ; Wed, 16 Dec 2020 18:42:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CBBD922516 for ; Wed, 16 Dec 2020 18:42:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731673AbgLPSmj (ORCPT ); Wed, 16 Dec 2020 13:42:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731667AbgLPSmj (ORCPT ); Wed, 16 Dec 2020 13:42:39 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CA6FC061794 for ; Wed, 16 Dec 2020 10:41:58 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id o19so25288256lfo.1 for ; Wed, 16 Dec 2020 10:41:58 -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=NBwMsdWQmCF/fPjOU/SBUXuDUFGMh+KiRZZ6DmIDumXHAq68+XMrBTI3YdEpWxdHd2 YmPNPVVtMhDO/YNRcJw1ACMfSVH1Y6qFac2f3JvHmP3yhA6cxp2RBK/S0TleocEoa2fN dN7Q5eFSCrAvQVZf8k7imACmF1UjfFa2SFvSk2sy5PcpcDoGCqNJC44L/odJX8mklrYF fcqAsiQuaaNRHs9huvE+DOcEw7ZhJiIXr/7KWXGuUCxq8kf28zA2i4eRKStclN7adum9 3nGxAwNitoPDMxYLzTos0UObxjSkgTJ0VpBg/xwwptby8Yx3YNun7JbrjcJAFCLt1IeV 30qg== X-Gm-Message-State: AOAM532mRf4ZBlUZT7p9cSLNLR+2dO7VLCMH48/8nnKSvBseB8WVTRoK vCrEJIcRTIYoTOdwNoP7/cRreeeVZ08vKQ== X-Google-Smtp-Source: ABdhPJweoWqERL1JY7tb4otcWZIwxznefBFSYu0c24qqTiJamC9kM+/RB1KBHIpqeIJqUggfr/LSHg== X-Received: by 2002:a2e:7d18:: with SMTP id y24mr8322203ljc.384.1608144115569; Wed, 16 Dec 2020 10:41:55 -0800 (PST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id x26sm312500lfe.173.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:54 -0800 (PST) Received: by mail-lf1-f50.google.com with SMTP id a9so50911594lfh.2 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 9D985C4361B for ; Wed, 16 Dec 2020 18:43:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2D7E72339E for ; Wed, 16 Dec 2020 18:43:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D7E72339E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=pLObF+FmVjj3e7Wr/ORIGvjM85QCgY9aCWfjhX/UaO0=; b=D6t2hgMaXHYJOvDicrF3lM5en nku+n0MxBTSUicmS+Hr1bZlYj3ndo6dfDfO0U7MItsijNRhpILqU9NlQhuRThAdOlio02bFNnqBoL EWYxQmpPDJx9hj8PHHx4CAlyrupBIlvuEBSPsI1n9s5Hj44+Fx5ajv2gKVPDPyIrNDtIq84U/rvUU LbJIc46MfRc8RAtdhDedlU1YoknaeKmQkMQnUdtSS3AENdenRGGRG6UoGReYPnJ6X3NE61G5XkoqW hCJ9eowMuOIH2l0g24Us0Fwk2RpjxihxUS5+MfUFXhJ2zfz678td571LbZTIZ+Kq6a7lBGLtWOubJ mJ0kJghEw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpbkQ-0003cu-BV; Wed, 16 Dec 2020 18:42:02 +0000 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpbkM-0003bV-OU for linux-arm-kernel@lists.infradead.org; Wed, 16 Dec 2020 18:41:59 +0000 Received: by mail-lf1-x12d.google.com with SMTP id o17so47988409lfg.4 for ; Wed, 16 Dec 2020 10:41:56 -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=SG4IOTB9+D2w+2vgloTM5g5kYreuAdHBzeaVUUV5znP4ZDOeE5Y2oWErW1W6QHvsk7 endoqWt2IgJuN2eDYJqvhTRt3OlRaZDjQsGUj93Yb7Yy3TOYZ4NmoA9O0q32VQngbgF0 7/9LtuV9zaPkVd6C2HttdbdLWYde4HHmsnNRvTEdiZBzfDDvvWq0DNniDR/Q8aj1ivUV x4e2WdeeUidryLBUaYH61ADglkL+V5CuIc9+cxO9ZlFwcec/eYzL5sp8taVFvKFTpNTq B344t7gDeLAPxaiavk0+dFVTBvFVJnPkLzX8SR/J3D46P6kLRptNi0tcnjQN7Iq1qRAQ sx7g== X-Gm-Message-State: AOAM531CDsQz8G9OGy3rqxwab2AaFojfEyc7rQ1UFnY+JA9npnWrFyoA YgTkzB2zG1d4kof/Pw4hkOMw+7dcHvE3Jg== X-Google-Smtp-Source: ABdhPJzZEOh51ylQwP2mFjPcBLY4HF2rob5y3c/j4UR8Cw7RK/KMNCyWw6WLl2nU034FLTjYrOg/Vw== X-Received: by 2002:a19:94f:: with SMTP id 76mr12709401lfj.642.1608144115126; Wed, 16 Dec 2020 10:41:55 -0800 (PST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id d2sm374191ljg.39.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-f47.google.com with SMTP id u18so50918993lfd.9 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" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201216_134158_927608_C1BC95F3 X-CRM114-Status: GOOD ( 16.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Android Kernel Team , Jan Kara , Minchan Kim , Catalin Marinas , Linux Kernel Mailing List , Matthew Wilcox , Linux-MM , Vinayak Menon , "Kirill A. Shutemov" , Andrew Morton , Will Deacon , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel