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.8 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 5C474C4727E for ; Fri, 25 Sep 2020 04:59:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8F0021D7F for ; Fri, 25 Sep 2020 04:59:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="J8aoXyUt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8F0021D7F 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 DCD806B005C; Fri, 25 Sep 2020 00:59:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D7C946B005D; Fri, 25 Sep 2020 00:59:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1DF38E0001; Fri, 25 Sep 2020 00:59:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0090.hostedemail.com [216.40.44.90]) by kanga.kvack.org (Postfix) with ESMTP id A24B66B005C for ; Fri, 25 Sep 2020 00:59:27 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6C9504417 for ; Fri, 25 Sep 2020 04:59:27 +0000 (UTC) X-FDA: 77300380374.26.touch19_290d07627164 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 496611804B655 for ; Fri, 25 Sep 2020 04:59:27 +0000 (UTC) X-HE-Tag: touch19_290d07627164 X-Filterd-Recvd-Size: 6699 Received: from mail-qv1-f67.google.com (mail-qv1-f67.google.com [209.85.219.67]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Sep 2020 04:59:26 +0000 (UTC) Received: by mail-qv1-f67.google.com with SMTP id ef16so723414qvb.8 for ; Thu, 24 Sep 2020 21:59:26 -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=9lveR0EfEXycscOiFjp8iB1hZRBuocElkDtt6NhPp+8=; b=J8aoXyUt/W4MWBZxCe+RV2QU01z9QdUF3sp7xESqbx7nJj4ofdkWVe7uoRY0Uhqw9b 2v27+GUeyJFNzTqeaQVKdgk9zS23qs0tZAMNPoAY3+3b4falT5jZ1Wt5Kq1SiD+OMHCK 9Mb0Fpsdo2m44QGoBHXRSi7fKVltOrPFhh4M0+hWogcRwkZYnfSzKQjaBoelHPY1Zu6y plbPQNxwcZ8nuxETZEa2pQfMnUQ37cC6ycEFkEgV1UTlQU9167KwnRapaLut8KtVJBp8 pMWDr130xUeyRCkZShEjRUCyPF2CHoOURZY5miaLI+5KB+YmXXVncumvnfx9UcJrszkm ckXw== 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=9lveR0EfEXycscOiFjp8iB1hZRBuocElkDtt6NhPp+8=; b=f2DWuopCKYVaIR/ABXHWVmImSvR6EZkfUVcg5f3U+CuMhfopdpQmsFfH7ZKrLgXRSj VzVxbi/BfQf/SLk6QyfHzudCrjrlqDVNItXt8iZFlMMVWRJ9+UnFD7nahGdYugm2Cnn+ vpw0WA16eDn9Qggz6OnH75BT2PWRryditwyn2Y4jPSXVaVTh80mTM0HTaPckxFI+acdf jDcD/KFHhGgMP6C0rKWw0MPhke3VLigy3lZ++s9lJLvLsZrqhGgXYNptOCkNhjERaEgP pqeMbEH4keW6gMtITYVrx7yAZUfudkI4rCgoMq3DTN42Mv7Mf19PHuCBo29Hp/XxmEsq UKmA== X-Gm-Message-State: AOAM531rn8+9+IszZ9IZS2nvbdt1y9FU3VuY+0wwKssDgd8vApfAD0sB ek67C+9fd9akPAf863gUMJoyGBwcGyS32+CMsQo= X-Google-Smtp-Source: ABdhPJxzW7OOnOvfFymZ6Oq6P+NBeoD6492ou9+Wg3YzK/7kGglVCEzlj5GhtG/K+Zdvf9fhirrjBfKarkCv+bnYNpI= X-Received: by 2002:a05:6214:903:: with SMTP id dj3mr2838395qvb.14.1601009966015; Thu, 24 Sep 2020 21:59:26 -0700 (PDT) MIME-Version: 1.0 References: <1598331582-19923-1-git-send-email-iamjoonsoo.kim@lge.com> <20200827133523.GC3090@techsingularity.net> In-Reply-To: From: Joonsoo Kim Date: Fri, 25 Sep 2020 13:59:15 +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-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 8=EC=9B=94 28=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 8:54, J= oonsoo Kim =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > 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 = prefer > > > > > to avoid it so this patch uses different way to skip CMA page all= ocation > > > > > from the pcplist. > > > > > > > > Well it would be much simpler and won't affect most of allocations.= Better 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 th= at > > 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 t= he > MIGRATE_HIGHATOMIC pageblock. It's reserved for highorder atomic > allocation so it's not good if an order-0 request could get there. It wou= ld > 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 = save > > 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 servic= ed > > 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 ma= ke > a rule even in internal implementation to make code simpler and maintaina= ble. > 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. Hello, Andrew and Vlastimil. It's better to fix this possible bug introduced in v5.9-rc1 before v5.9 is released. Which approach do you prefer? If it is determined, I will immediately send a patch as you suggested. Thanks.