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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4531C433EF for ; Wed, 11 May 2022 22:37:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57A616B0074; Wed, 11 May 2022 18:37:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 503EF6B0075; Wed, 11 May 2022 18:37:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 359DC6B0078; Wed, 11 May 2022 18:37:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 253936B0074 for ; Wed, 11 May 2022 18:37:17 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 07CAB818D4 for ; Wed, 11 May 2022 22:37:17 +0000 (UTC) X-FDA: 79454924514.11.70DA4D2 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf01.hostedemail.com (Postfix) with ESMTP id 810BC400AC for ; Wed, 11 May 2022 22:37:04 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id n18so3215521plg.5 for ; Wed, 11 May 2022 15:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nehdr7PITXzy3bqyFSTIHEYGzvy9BmPaO54SUkuQJus=; b=Yt4rmSeljKAy4zVAJt38bsEUP+R/ch5xnFMH1IcPKPcH9fhCkYfitu2Bz7DZr64Zgs zS0pxud8f1P0frTY4URR6vlv3jGV2gOh3d2DoucZdDjS4qr2Ga274DQHMeLlYcGIMbIn XPEghnlayuephnbpvOaYmlbtLLreK1cfBskDVzqqLxbBiJPmBPOKPyQ63VJRnRRBugWA 4hnNM8TnPq6TnqkREYiyo66NBdJtZhaV8tqUioqmgbIp4nEUvzcPr/S0Ax+iNvOKKsnL YE2/8Lb1fsSmQbLe6bDPxO0Pc2BxY+we5Y4fvoti9aZSjgjwqfd7JrSBugkX4K1Tp87B tAZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=nehdr7PITXzy3bqyFSTIHEYGzvy9BmPaO54SUkuQJus=; b=7SLrHbxgho1I+SCcm7gTQ4Q/tOnRezPk01QE26cHrcN8U/o99wncXuLR4L33YpdulL kC/rLEn1QFezHiJ/2IIKFeGCOhxdsvydGVvptpGvglLX5U0ngZriOLPqIe/X6JP3uKE9 ntX+aosyYFRx9u0wGIT1rQD7PopFp0lR0GYq7iascrKUDmjHQnnJH7l7t8vSC/AsKblD c0IwTN3tOBlqb0gu+/HzMPVfgJkGNb6aAMasTRHWc0QpAD3lC1hnwquXg3MXVOOg5e+Z oUmf+u56kW7Ah+bSNrTPDT8873Eu/VZP+CmOGsSRAu9R2zzRTlVjWWOoDQSfFrHsJMRA V+tA== X-Gm-Message-State: AOAM533tlXJArYs2OvnBLVlZCNXitmlIN/eYny48G9naPmxiUso6/LPD ETEo4BKMaAbMZwgKDph7rRo= X-Google-Smtp-Source: ABdhPJzyASJ01em+i4TBSflUo8jGKENF4EVaVlb3eN6NoOzTtMFrNN1ofuibrUqvb/9Z2fzC0MC73Q== X-Received: by 2002:a17:902:bb92:b0:153:4eae:c77e with SMTP id m18-20020a170902bb9200b001534eaec77emr27112543pls.93.1652308635389; Wed, 11 May 2022 15:37:15 -0700 (PDT) Received: from google.com ([2620:15c:211:201:69ef:9c87:7816:4f74]) by smtp.gmail.com with ESMTPSA id l7-20020a170902f68700b0015e8d4eb2e9sm2469090plg.307.2022.05.11.15.37.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 May 2022 15:37:15 -0700 (PDT) Date: Wed, 11 May 2022 15:37:13 -0700 From: Minchan Kim To: John Hubbard Cc: Andrew Morton , linux-mm , LKML , "Paul E . McKenney" , John Dias , David Hildenbrand Subject: Re: [PATCH v4] mm: fix is_pinnable_page against on cma page Message-ID: References: <20220510211743.95831-1-minchan@kernel.org> <857d21da-5de2-fa3e-b1ce-41cc1cfb0191@nvidia.com> <2ffa7670-04ea-bb28-28f8-93a9b9eea7e8@nvidia.com> <54b5d177-f2f4-cef2-3a68-cd3b0b276f86@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54b5d177-f2f4-cef2-3a68-cd3b0b276f86@nvidia.com> X-Rspamd-Queue-Id: 810BC400AC X-Stat-Signature: 86ksttihjmgqx7jte9sz61twuht9qebm X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Yt4rmSel; spf=pass (imf01.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Rspamd-Server: rspam09 X-HE-Tag: 1652308624-542392 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, May 11, 2022 at 03:25:49PM -0700, John Hubbard wrote: > On 5/11/22 2:46 PM, Minchan Kim wrote: > > > I read that, but there was never any real justification there for needing > > > to prevent a re-read of mt, just a preference: "I'd like to keep use the local > > > variable mt's value in folloing conditions checks instead of refetching > > > the value from get_pageblock_migratetype." > > > > > > But I don't believe that there is any combination of values of mt that > > > will cause a problem here. > > > > > > I also think that once we pull in experts, they will tell us that the > > > compiler is not going to re-run a non-trivial function to re-fetch a > > > value, but I'm not one of those experts, so that's still arguable. But > > > imagine what the kernel code would look like if every time we call > > > a large function, we have to consider if it actually gets called some > > > arbitrary number of times, due to (anti-) optimizations by the compiler. > > > This seems like something that is not really happening. > > > > Maybe, I might be paranoid since I have heard too subtle things > > about how compiler could changes high level language code so wanted > > be careful especially when we do lockless-stuff. > > > > Who cares when we change the large(?) function to small(?) function > > later on? I'd like to hear from experts to decide it. > > > > Yes. But one thing that is still unanswered, that I think you can > answer, is: even if the compiler *did* re-read the mt variable, what > problems could that cause? I claim "no problems", because there is > no combination of 0, _CMA, _ISOLATE, _CMA|ISOLATE that will cause > problems here. What scenario I am concerning with __READ_ONCE so compiler inlining get_pageblock_migratetype two times are CPU 0 CPU 1 alloc_contig_range is_pinnable_page start_isolate_page_range set_pageblock_migratetype(MIGRATE_ISOLATE) if (get_pageeblock_migratetype(page) == MIGRATE_CMA) so it's false undo: set_pageblock_migratetype(MIGRATE_CMA) if (get_pageeblock_migratetype(page) == MIGRATE_ISOLATE) so it's false In the end, CMA memory would be pinned by CPU 0 process so CMA allocation keep failed until the process release the refcount. > > Any if that's true, then we can leave the experts alone, because > the answer is there without knowing what happens exactly to mt. > > thanks, > > -- > John Hubbard > NVIDIA >