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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 A8FDDC4724C for ; Fri, 1 May 2020 10:52:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56A1C2184D for ; Fri, 1 May 2020 10:52:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="V9WxwNF2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56A1C2184D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D9F4D8E0014; Fri, 1 May 2020 06:52:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D507F8E0001; Fri, 1 May 2020 06:52:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3E6D8E0014; Fri, 1 May 2020 06:52:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id ACE7F8E0001 for ; Fri, 1 May 2020 06:52:48 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7A92C4DDD for ; Fri, 1 May 2020 10:52:48 +0000 (UTC) X-FDA: 76767837216.19.bread91_3592974281207 X-HE-Tag: bread91_3592974281207 X-Filterd-Recvd-Size: 9334 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 1 May 2020 10:52:48 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id g26so3736750qtv.13 for ; Fri, 01 May 2020 03:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CKSWEhR47OrXn/8dOC2MOqQVcUKFbmXG90P7o5aVE8c=; b=V9WxwNF2rHyEYvnA0zGGt8w7B58qoUIf9ewJ5d1B8wOGtvxFNIAsipVA5Y9CRz61gK NaT8/XnkaR+L0+bCE0Hyx1LUvo/YXMQVK2GL/LpLChR2wN1+QwNE9lTEkkslIK6GqZXh oNLTdhuMVcfSDyEYzBnUNqmoLpYGQiIfl19++n+I8I3nE6CzjWNAiNnrYDZa68gibmcs dQSqWa1xywl9UbC0Y/SfwOOrRBY5PGOy3soSGH7Yk0YZyg79JzXeKIx5U5uDAnOAQ0Bp 9MF2dlrjWkV051D393hydRx9YYhMfKWstNiauG7G8bFe7VeAz0iZx5nRJ8xiDDOOi6Dv cHCQ== 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:content-transfer-encoding; bh=CKSWEhR47OrXn/8dOC2MOqQVcUKFbmXG90P7o5aVE8c=; b=GicUUdgLjJxeQJ52KdsAWaC+EmxZ99LXsgevj99LLn5PHXdaofVU2qQH7A3ZO5+E5F p+tKPpwUBhzfbzsID0i5TlIdw+UlNSvRsSOI6rWSavoWawuNdxdtqITEWPlbv03pX+YH z9RS7DNO0MLsCtWp5FRcVsPaJlfVQreCJgnxVxGlZ1fSnEkXZvnQJ3a7/JP5L2WimG5n DPXA2IgJ51zYaEzqZps7wx/W+WnES7Lv9FP8+4P23inEdS1zIDgYjrKr+TB1O0sAWfzm KpJBPhSt5UjJ/RksqS7j2dNDeq/xg3QeF0zTa1MV8K3dFzk/j5oay6K9rS4Awo/LCyA6 ldmQ== X-Gm-Message-State: AGi0PubLU5+TRYfCA+Uda1YQ0Bjm7RKDjif+9vUHU9Jn6rbqsoGnnw5X qvPHII36sPjJSOYtJZ0SRplpNsYX8T+vHToCtXk= X-Google-Smtp-Source: APiQypKXjEL1RmHTSzXwlVnlyybCY6qyE6NYilstbhLWFeHgxL09NfX2tGRosNYxqEU3zw3qGm+peP0ETc3l5lTBCQI= X-Received: by 2002:ac8:724b:: with SMTP id l11mr3265642qtp.35.1588330367309; Fri, 01 May 2020 03:52:47 -0700 (PDT) MIME-Version: 1.0 References: <1588130803-20527-1-git-send-email-iamjoonsoo.kim@lge.com> <20200429184711.9d603da097fdea80f574f1f1@linux-foundation.org> In-Reply-To: <20200429184711.9d603da097fdea80f574f1f1@linux-foundation.org> From: Joonsoo Kim Date: Fri, 1 May 2020 19:52:35 +0900 Message-ID: Subject: Re: [PATCH v2 00/10] change the implementation of the PageHighMem() To: Andrew Morton Cc: Linux Memory Management List , LKML , Vlastimil Babka , Laura Abbott , "Aneesh Kumar K . V" , Mel Gorman , Michal Hocko , Johannes Weiner , Roman Gushchin , Minchan Kim , Rik van Riel , Christian Koenig , Huang Rui , Eric Biederman , "Rafael J . Wysocki" , Pavel Machek , kernel-team@lge.com, Christoph Hellwig , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: 2020=EB=85=84 4=EC=9B=94 30=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 10:47, = Andrew Morton =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84= =B1: > > On Wed, 29 Apr 2020 12:26:33 +0900 js1304@gmail.com wrote: > > > From: Joonsoo Kim > > > > Changes on v2 > > - add "acked-by", "reviewed-by" tags > > - replace PageHighMem() with use open-code, instead of using > > new PageHighMemZone() macro. Related file is "include/linux/migrate.h" > > > > Hello, > > > > This patchset separates two use cases of PageHighMem() by introducing > > PageHighMemZone() macro. And, it changes the implementation of > > PageHighMem() to reflect the actual meaning of this macro. This patchse= t > > is a preparation step for the patchset, > > "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE" [= 1]. > > > > PageHighMem() is used for two different cases. One is to check if there > > is a direct mapping for this page or not. The other is to check the > > zone of this page, that is, weather it is the highmem type zone or not. > > > > Until now, both the cases are the perfectly same thing. So, implementat= ion > > of the PageHighMem() uses the one case that checks if the zone of the p= age > > is the highmem type zone or not. > > > > "#define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))" > > > > ZONE_MOVABLE is special. It is considered as normal type zone on > > !CONFIG_HIGHMEM, but, it is considered as highmem type zone > > on CONFIG_HIGHMEM. Let's focus on later case. In later case, all pages > > on the ZONE_MOVABLE has no direct mapping until now. > > > > However, following patchset > > "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE" > > , which is once merged and reverted, will be tried again and will break > > this assumption that all pages on the ZONE_MOVABLE has no direct mappin= g. > > Hence, the ZONE_MOVABLE which is considered as highmem type zone could > > have the both types of pages, direct mapped and not. Since > > the ZONE_MOVABLE could have both type of pages, __GFP_HIGHMEM is still > > required to allocate the memory from it. And, we conservatively need to > > consider the ZONE_MOVABLE as highmem type zone. > > > > Even in this situation, PageHighMem() for the pages on the ZONE_MOVABLE > > when it is called for checking the direct mapping should return correct > > result. Current implementation of PageHighMem() just returns TRUE > > if the zone of the page is on a highmem type zone. So, it could be wron= g > > if the page on the MOVABLE_ZONE is actually direct mapped. > > > > To solve this potential problem, this patch introduces a new > > PageHighMemZone() macro. In following patches, two use cases of > > PageHighMem() are separated by calling proper macro, PageHighMem() and > > PageHighMemZone(). Then, implementation of PageHighMem() will be change= d > > as just checking if the direct mapping exists or not, regardless of > > the zone of the page. > > > > Note that there are some rules to determine the proper macro. > > > > 1. If PageHighMem() is called for checking if the direct mapping exists > > or not, use PageHighMem(). > > 2. If PageHighMem() is used to predict the previous gfp_flags for > > this page, use PageHighMemZone(). The zone of the page is related to > > the gfp_flags. > > 3. If purpose of calling PageHighMem() is to count highmem page and > > to interact with the system by using this count, use PageHighMemZone(). > > This counter is usually used to calculate the available memory for an > > kernel allocation and pages on the highmem zone cannot be available > > for an kernel allocation. > > 4. Otherwise, use PageHighMemZone(). It's safe since it's implementatio= n > > is just copy of the previous PageHighMem() implementation and won't > > be changed. > > hm, this won't improve maintainability :( > > - Everyone will need to remember when to use PageHighMem() and when > to use PageHighMemZone(). If they get it wrong, they're unlikely to > notice any problem in their runtime testing, correct? > > - New code will pop up which gets it wrong and nobody will notice for > a long time. Hmm... I think that it's not that hard to decide correct macro. If we renam= e PageHighMem() with PageDirectMapped(), they, PageDirectMapped() and PageHighMemZone(), are self-explanation macro. There would be no confusion to use. > So I guess we need to be pretty confident that the series "mm/cma: > manage the memory of the CMA area by using the ZONE_MOVABLE" will be > useful and merged before proceeding with this, yes? Yes and my assumption is that we (MM) have agreed with usefulness of CMA series. > On the other hand, this whole series is a no-op until [10/10] > (correct?) so it can be effectively reverted with a single line change, Correct! > with later cleanups which revert the other 9 patches. > > So I think I'd like to take another look at "mm/cma: manage the memory > of the CMA area by using the ZONE_MOVABLE" before figuring out what to > do here. Mainly to answer the question "is the new feature valuable > enough to justify the maintainability impact". So please do take some > care in explaining the end-user benefit when preparing the new version > of that patchset. So, do you mean to send the new version of CMA patchset with more explanation before merging this patchset? If yes, I can do. But, I'm not su= re that it's worth doing. Problems of CMA are still not solved although the utilization problem will be partially solved by Roman's "mm,page_alloc,= cma: conditionally prefer cma pageblocks for movable allocations" patch in this (v5.7) release. Rationale that we agree with CMA patchset is still remained. Anyway, if you mean that, I will send the CMA patchset with more explanatio= n. Thanks.