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=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham 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 11229C4363D for ; Tue, 22 Sep 2020 19:11:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 70DD420BED for ; Tue, 22 Sep 2020 19:11:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="MXGd/Nnx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 70DD420BED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BADB36B0003; Tue, 22 Sep 2020 15:11:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5D1F6B0055; Tue, 22 Sep 2020 15:11:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4BBE6B005A; Tue, 22 Sep 2020 15:11:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id 8C5276B0003 for ; Tue, 22 Sep 2020 15:11:06 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4FAFC181AC9C6 for ; Tue, 22 Sep 2020 19:11:06 +0000 (UTC) X-FDA: 77291640132.15.suit33_01093d227150 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 223C21814B0C8 for ; Tue, 22 Sep 2020 19:11:06 +0000 (UTC) X-HE-Tag: suit33_01093d227150 X-Filterd-Recvd-Size: 4701 Received: from hqnvemgate25.nvidia.com (hqnvemgate25.nvidia.com [216.228.121.64]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Sep 2020 19:11:05 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Tue, 22 Sep 2020 12:10:17 -0700 Received: from [10.2.52.174] (172.20.13.39) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 22 Sep 2020 19:11:03 +0000 Subject: Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned To: Peter Xu CC: , , Jason Gunthorpe , Andrew Morton , Jan Kara , Michal Hocko , Kirill Tkhai , Kirill Shutemov , Hugh Dickins , Christoph Hellwig , Andrea Arcangeli , Oleg Nesterov , Leon Romanovsky , Linus Torvalds , "Jann Horn" References: <20200921211744.24758-1-peterx@redhat.com> <20200921211744.24758-2-peterx@redhat.com> <224908c1-5d0f-8e01-baa9-94ec2374971f@nvidia.com> <20200922151736.GD19098@xz-x1> From: John Hubbard Message-ID: <68a95df9-87eb-86c8-4a80-cb1421884e51@nvidia.com> Date: Tue, 22 Sep 2020 12:11:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200922151736.GD19098@xz-x1> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1600801817; bh=Y4P3+5U25Weu7EkCQ0DqguAbg7GLoekbh+l+VhO64gI=; h=Subject:To:CC:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=MXGd/NnxuhFTFj1EURN6eETl8lKwXRX8YFZ9NPQfCnbmORXuZCjEUeMcY0NO69M5M 3J5DQ/YAQOfF4sFVIt/gDTSBQx+522GGN1z3xpWGi6lgA1yjbRWk2s+vqR0YlwbtPh Sn6ZCvugRm3r1/KL4nuo+SofukdvwWDCOLBgZMyXLzleEdyn8JsdBfEPxNcIhxn4W0 jSfgBFuqHFgdQs7WC/+W+0yPxIyuipfEif5n/xhz3Q2YiRb3+C/8Q4R0fau2p1uWZZ mvt91gz2IULtGV3bfC6XXxwm92fDnhWiSAJgewXYIxzCyBfwUi7uxdXR2hN520vm7K mY0reffpibNzQ== 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 9/22/20 8:17 AM, Peter Xu wrote: > On Mon, Sep 21, 2020 at 04:53:38PM -0700, John Hubbard wrote: >> On 9/21/20 2:17 PM, Peter Xu wrote: ... >>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h >>> index 496c3ff97cce..6f291f8b74c6 100644 >>> --- a/include/linux/mm_types.h >>> +++ b/include/linux/mm_types.h >>> @@ -441,6 +441,16 @@ struct mm_struct { >>> #endif >>> int map_count; /* number of VMAs */ >>> + /** >>> + * @has_pinned: Whether this mm has pinned any pages. This can >>> + * be either replaced in the future by @pinned_vm when it >>> + * becomes stable, or grow into a counter on its own. We're >>> + * aggresive on this bit now - even if the pinned pages were >>> + * unpinned later on, we'll still keep this bit set for the >>> + * lifecycle of this mm just for simplicity. >>> + */ >>> + int has_pinned; >> >> I think this would be elegant as an atomic_t, and using atomic_set() and >> atomic_read(), which seem even more self-documenting that what you have here. >> >> But it's admittedly a cosmetic point, combined with my perennial fear that >> I'm missing something when I look at a READ_ONCE()/WRITE_ONCE() pair. :) > > Yeah but I hope I'm using it right.. :) I used READ_ONCE/WRITE_ONCE explicitly > because I think they're cheaper than atomic operations, (which will, iiuc, lock > the bus). > The "cheaper" argument vanishes if the longer-term plan is to use atomic ops. Given the intent of this patchset, simpler is better, and "simpler that has the same performance as the longer term solution" is definitely OK. >> >> It's completely OK to just ignore this comment, but I didn't want to completely >> miss the opportunity to make it a tiny bit cleaner to the reader. > > This can always become an atomic in the future, or am I wrong? Actually if > we're going to the counter way I feel like it's a must. > Yes it can change. But you can get the simplicity and clarity now, rather than waiting. thanks, -- John Hubbard NVIDIA