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.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 40A6EC433E6 for ; Thu, 27 Aug 2020 23:54:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ECD272074F for ; Thu, 27 Aug 2020 23:54:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QwDD//o7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECD272074F 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 8E3BA6B0003; Thu, 27 Aug 2020 19:54:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 870D56B0008; Thu, 27 Aug 2020 19:54:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 734A76B000C; Thu, 27 Aug 2020 19:54:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id 5A23F6B0003 for ; Thu, 27 Aug 2020 19:54:57 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 17A98181AEF07 for ; Thu, 27 Aug 2020 23:54:57 +0000 (UTC) X-FDA: 77198006634.09.toys45_26161d427071 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id E44A1180AD81A for ; Thu, 27 Aug 2020 23:54:56 +0000 (UTC) X-HE-Tag: toys45_26161d427071 X-Filterd-Recvd-Size: 6092 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Thu, 27 Aug 2020 23:54:56 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id o196so7316043qke.8 for ; Thu, 27 Aug 2020 16:54:56 -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=tPhhvVGwKSAuel8jNNMpBV2hW2oRk0ci2Ch7jocIK7o=; b=QwDD//o7ub1e8O2Borzvx0WyXnIdXAuWfDG1wLF+F+5FTCHlBOlmcet+/rXszmjfFc 2XYG0oOODYXZRxVC8OGmK/cFJ0+sMN4Ng8Ge1N+b8hk+YOFN2RDg8xF4UZJiieuqiAt/ A4wHbV7iC5GIVEVdBt3yH57efZWhYLoo1Rs6kdoBFnpQpoHy/JBTekdjVU/RFMlk3Fxq 0UocONyTMlnNXh84kD3aQZ/+iwlSCUyjazJQbrVPMGel4OAuMud3ca5ypb+ZFyCuKKLU PsNx+hpyVFXPdlbhb+ODNv3ebvmETIpjtmLJos5+HrGX3Q+xzbZAQ9y5X/Hc05ieRo0+ W6ag== 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=tPhhvVGwKSAuel8jNNMpBV2hW2oRk0ci2Ch7jocIK7o=; b=WPVh5ReZAv5BtpJVvN9hyag9hNZRWVRKJ5HdFKeZWAjp1MNU51sEKgYnBmpOQE8Tb6 wsQWbS3JJ9ts5pMTqnw02+TMjot2k2AqpPBP4JzbGSSxrdSXvnbSnxqOh9iozG7P80bO CkmX/n6DHcIRKbcjHKnA+ss6L7J/j9BrC43bwtcuPKxLbzlTjySdQOARcOsCj1ON1u4b Fscad68bEdU3qRdgC7+m8T1750Kdf788V9U2o1qT0/+9OgHqlnUWM65HJpZLGe7vc3tu UEtuB5F+DOava/30WmxqSIC1GF/LxkoltCWC4eYoyidYXByMf9ExDMX5fowjlknmtArP zYdg== X-Gm-Message-State: AOAM533DVES8kAKlNU+C6JDpfiR/gc3L8Jw54JzCiw2vIQYh69GCFkZg jqKNWATyZOkgixdBoJeH6Q0rQHxNEBi67yEwIFk= X-Google-Smtp-Source: ABdhPJw/XngZSnCgwjpPwdGCdAsF1zFP1OuZnj/kBJ14DG7/Ch/KvdZinGXKodKEO5+FW20SlBbu7ZOdAgSYnLGQaD4= X-Received: by 2002:a37:d8d:: with SMTP id 135mr4611687qkn.59.1598572495641; Thu, 27 Aug 2020 16:54:55 -0700 (PDT) MIME-Version: 1.0 References: <1598331582-19923-1-git-send-email-iamjoonsoo.kim@lge.com> <20200827133523.GC3090@techsingularity.net> In-Reply-To: <20200827133523.GC3090@techsingularity.net> From: Joonsoo Kim Date: Fri, 28 Aug 2020 08:54:44 +0900 Message-ID: Subject: Re: [PATCH for v5.9] mm/page_alloc: handle a missing case for memalloc_nocma_{save/restore} APIs To: Mel Gorman Cc: Vlastimil Babka , Andrew Morton , Linux Memory Management List , LKML , Michal Hocko , "Aneesh Kumar K . V" , kernel-team@lge.com, Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E44A1180AD81A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 2020=EB=85=84 8=EC=9B=94 27=EC=9D=BC (=EB=AA=A9) =EC=98=A4=ED=9B=84 10:35, = Mel Gorman =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84= =B1: > > On Wed, Aug 26, 2020 at 02:12:44PM +0900, Joonsoo Kim wrote: > > > > And, it requires to break current code > > > > layering that order-0 page is always handled by the pcplist. I'd pr= efer > > > > to avoid it so this patch uses different way to skip CMA page alloc= ation > > > > from the pcplist. > > > > > > Well it would be much simpler and won't affect most of allocations. B= etter than > > > flushing pcplists IMHO. > > > > Hmm...Still, I'd prefer my approach. > > I prefer the pcp bypass approach. It's simpler and it does not incur a > pcp drain/refill penalty. > > > There are two reasons. First, > > layering problem > > mentioned above. In rmqueue(), there is a code for MIGRATE_HIGHATOMIC. > > As the name shows, it's for high order atomic allocation. But, after > > skipping pcplist > > allocation as you suggested, we could get there with order 0 request. > > I guess your concern is that under some circumstances that a request that > passes a watermark check could fail due to a highatomic reserve and to > an extent this is true. However, in that case the system is already low > on memory depending on the allocation context, the pcp lists may get > flushed anyway. My concern is that non-highorder (order-0) allocation could pollute/use the MIGRATE_HIGHATOMIC pageblock. It's reserved for highorder atomic allocation so it's not good if an order-0 request could get there. It would cause more fragmentation on that pageblock. > > We can also > > change this code, but, I'd hope to maintain current layering. Second, > > a performance > > reason. After the flag for nocma is up, a burst of nocma allocation > > could come. After > > flushing the pcplist one times, we can use the free page on the > > pcplist as usual until > > the context is changed. > > It's not guaranteed because CMA pages could be freed between the nocma sa= ve > and restore triggering further drains due to a reschedule. Similarly, > a CMA allocation in parallel could refill with CMA pages on the per-cpu > list. While both cases are unlikely, it's more unpredictable than a > straight-forward pcp bypass. Agreed that it's unpredictable than the pcp bypass. But, as you said, those cases would be rare. > I don't really see it as a layering violation of the API because all > order-0 pages go through the PCP lists. The fact that order-0 is serviced > from the pcp list is an internal implementation detail, the API doesn't > care. What I mean is an internal implementation layering violation. We could make a rule even in internal implementation to make code simpler and maintainabl= e. I guess that order-0 is serviced from the pcp list is one of those. Anyway, although I prefer my approach, I'm okay with using pcp bypass. Thanks.