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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 EEA6FC4727E for ; Thu, 24 Sep 2020 18:49:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 763262311E for ; Thu, 24 Sep 2020 18:49:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="iSFnDkmH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 763262311E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BA77D6B005C; Thu, 24 Sep 2020 14:49:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B30176B005D; Thu, 24 Sep 2020 14:49:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D1096B0062; Thu, 24 Sep 2020 14:49:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 83D806B005C for ; Thu, 24 Sep 2020 14:49:45 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 44FC5180AD806 for ; Thu, 24 Sep 2020 18:49:45 +0000 (UTC) X-FDA: 77298843930.21.crowd26_3e156e627161 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 1A539180442C3 for ; Thu, 24 Sep 2020 18:49:45 +0000 (UTC) X-HE-Tag: crowd26_3e156e627161 X-Filterd-Recvd-Size: 7558 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Sep 2020 18:49:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600973384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XtEnp20rlhLwsWsIBELxeQUjAOInolF5ll32kJfBQNc=; b=iSFnDkmHA+Xl4i8yv73woRfWoI8HgOxno0eO6oBy6XOGjVg3On167qpqJU8SteAmtsZ579 Tsfmk6I1Z2/zl4VnVf8P8khxvTmrtGIq1zn5QunLsm979vu21zNuMDkdSDTn6m+N+e2B3o aHssXhC54DqMssEf1Pbk/nWtTJwgXvE= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-498-sDrw-uqeOJ6Ffb2mYMnRwg-1; Thu, 24 Sep 2020 14:49:40 -0400 X-MC-Unique: sDrw-uqeOJ6Ffb2mYMnRwg-1 Received: by mail-qt1-f197.google.com with SMTP id f12so66707qtq.5 for ; Thu, 24 Sep 2020 11:49:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XtEnp20rlhLwsWsIBELxeQUjAOInolF5ll32kJfBQNc=; b=c2KZw01dH84dJCwW9ZXhRiWLzrCrMKJmIh5gyb60LOT8QOePKTDyPVKbAxtLvXnArO UTVf33Bjtqv6SOQuBw3AjqHnSDBPVH1Jt/5Y9DD47BwzXfqMjE+qH6UMk4EusQakjXbM SPZTySZsvLb1aaHV/0K6y+cmZDh6Zy/S9z9rKKpyi7THcOjc9NUxnXGYbvFv/FbXFRQN QmGxmvPpSnTiFsTyt39OWtoTK856C4Xty+nVwDHP0UrBvsZwbIOjTMT96kDKqCsRJSii kdbu8g5jzH+M+lYAV30wguiKhcGEQgCswEspEqmgSnxELXLTOVBJevtW5s6XBzqoD8VG JL8w== X-Gm-Message-State: AOAM530TKLGhi1G9txf4WidGCtui+/tOJGxlTrkbHQec4EWNbNoQdqCP 3J8smCMjZ+eUIaP5T10xv5bKss5oqJj6VBQZYAUSwq5wIJgJ9LIdwzyjQwfJh39mCzh4IoMTATH hnkJc3me3+38= X-Received: by 2002:ac8:5317:: with SMTP id t23mr562879qtn.354.1600973379896; Thu, 24 Sep 2020 11:49:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymPUpe7nv5fBAQLKetJacV27ezUU4s/tjW7RrHSORRJ4fxMpgEArQt9AtYEHKSz8Y71wmyDw== X-Received: by 2002:ac8:5317:: with SMTP id t23mr562854qtn.354.1600973379627; Thu, 24 Sep 2020 11:49:39 -0700 (PDT) Received: from xz-x1 (bras-vprn-toroon474qw-lp130-11-70-53-122-15.dsl.bell.ca. [70.53.122.15]) by smtp.gmail.com with ESMTPSA id g5sm261530qtx.43.2020.09.24.11.49.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2020 11:49:38 -0700 (PDT) Date: Thu, 24 Sep 2020 14:49:37 -0400 From: Peter Xu To: John Hubbard Cc: Jan Kara , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Linus Torvalds , Michal Hocko , Kirill Shutemov , Jann Horn , Oleg Nesterov , Kirill Tkhai , Hugh Dickins , Leon Romanovsky , Christoph Hellwig , Andrew Morton , Jason Gunthorpe , Andrea Arcangeli Subject: Re: [PATCH 5/5] mm/thp: Split huge pmds/puds if they're pinned when fork() Message-ID: <20200924184937.GK79898@xz-x1> References: <20200921211744.24758-1-peterx@redhat.com> <20200921212031.25233-1-peterx@redhat.com> <5e594e71-537f-3e9f-85b6-034b7f5fedbe@nvidia.com> <20200922103315.GD15112@quack2.suse.cz> <4a65586e-9282-beb0-1880-1ef8da03727c@nvidia.com> <20200923092205.GA6719@quack2.suse.cz> <20200923135004.GB59978@xz-x1> <20200923140114.GA15875@quack2.suse.cz> <20200923154418.GE59978@xz-x1> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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, Sep 23, 2020 at 01:19:08PM -0700, John Hubbard wrote: > On 9/23/20 8:44 AM, Peter Xu wrote: > > On Wed, Sep 23, 2020 at 04:01:14PM +0200, Jan Kara wrote: > > > On Wed 23-09-20 09:50:04, Peter Xu wrote: > ... > > > > > But the problem is that if you apply mm->has_pinned check on file pages, > > > > > you can get false negatives now. And that's not acceptable... > > > > > > > > Do you mean the case where proc A pinned page P from a file, then proc B > > > > mapped the same page P on the file, then fork() on proc B? > > > > > > Yes. > > aha, thanks for spelling out the false negative problem. > > > > > > > > If proc B didn't explicitly pinned page P in B's address space too, > > > > shouldn't we return "false" for page_likely_dma_pinned(P)? Because if > > > > proc B didn't pin the page in its own address space, I'd think it's ok to > > > > get the page replaced at any time as long as the content keeps the same. > > > > Or couldn't we? > > > > > > So it depends on the reason why you call page_likely_dma_pinned(). For your > > > COW purposes the check is correct but e.g. for "can filesystem safely > > > writeback this page" the page_likely_dma_pinned() would be wrong. So I'm > > > not objecting to the mechanism as such. I'm mainly objecting to the generic > > > function name which suggests something else than what it really checks and > > > thus it could be used in wrong places in the future... That's why I'd > > > prefer to restrict the function to PageAnon pages where there's no risk of > > > confusion what the check actually does. > > > > How about I introduce the helper as John suggested, but rename it to > > > > page_maybe_dma_pinned_by_mm() > > > > ? > > > > Then we also don't need to judge on which is more likely to happen (between > > "maybe" and "likely", since that will confuse me if I only read these words..). > > > > You're right, it is too subtle of a distinction after all. I agree that sticking > with "_maybe_" avoids that confusion. > > > > I didn't use any extra suffix like "cow" because I think it might be useful for > > things besides cow. Fundamentally the new helper will be mm-based, so "by_mm" > > seems to suite better to me. > > > > Does that sound ok? > > > > Actually, Jan nailed it. I just wasn't understanding his scenario, but now that > I do, and considering your other point about wording, I think we end up with: > > anon_page_maybe_pinned() > > as a pretty good name for a helper function. (We don't want "_mm" because that > refers more to the mechanism used internally, rather than the behavior of the > function. "anon_" adds more meaning.) Actually it was really my intention when I suggested "_by_mm", because IMHO the new helper actually means "whether this page may be pinned by _this mm_ (not any other address space)". IOW, the case that Jan mentioned on the share page can be reflected in this case, because although that page was pinned, however it was not pinned "by this mm" for e.g. proc B above. Though I've no strong opinion either. I'll start with anon_page_maybe_pinned(). To me it's probably more important to prepare the next spin first and see whether we'd still like it for this release. Thanks, -- Peter Xu