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 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 E63E8C433DF for ; Wed, 26 Aug 2020 05:12:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7208D206FA for ; Wed, 26 Aug 2020 05:12:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hYKvrPyv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7208D206FA 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 9E66E6B0006; Wed, 26 Aug 2020 01:12:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96EEC6B0007; Wed, 26 Aug 2020 01:12:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8368F6B0008; Wed, 26 Aug 2020 01:12:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id 697EE6B0006 for ; Wed, 26 Aug 2020 01:12:56 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 13220181AEF1A for ; Wed, 26 Aug 2020 05:12:56 +0000 (UTC) X-FDA: 77191550352.23.bear14_1e0cd2d27061 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id D015A37604 for ; Wed, 26 Aug 2020 05:12:55 +0000 (UTC) X-HE-Tag: bear14_1e0cd2d27061 X-Filterd-Recvd-Size: 5238 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Wed, 26 Aug 2020 05:12:55 +0000 (UTC) Received: by mail-qt1-f171.google.com with SMTP id t23so595025qto.3 for ; Tue, 25 Aug 2020 22:12:55 -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=yfilLBz5JZdi/avFWO9tv5bRcdRvux+Y1JNGa63+Zro=; b=hYKvrPyvirHQ+xAzWDhhq/Ve3fZvfDkw5fuDGO3+OfWWm1ofs9zDsoDjyMvL+nPnSD gs0YfdCzHTHaFwZTQP+iqBv82s7JY+1XrsnNfWmUyj4qJF40prRBc63skwRCZJbNHsuA Me92vZt7MTLa083lH4yQNIH/6bOKrvKscPPAXJvjmhYeTA1Xguf/YUQBzFyNDYoU+3Lj vzHg4aUmM3RX451EBuADsyD3WpYoPIXv+r/3t/HK1qvwno5cQ0DT0P3qnAHKQZf7utgB zkPp/qpPx/xiQe/xa8V8yerURt0qsvUun9nocWJKFvK84ZN0zm8AXmtk2s3USdvh6xQC VHng== 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=yfilLBz5JZdi/avFWO9tv5bRcdRvux+Y1JNGa63+Zro=; b=m9HSuFIU/otHyBcQYS+EiGeZsyhhDAXVEoD4oPkKpCoT4wz5dMLie+2psJ43f3IuS2 T5skPW922k6pWwZCh74xfmLbBB/Q9vh5gDfC35WHDE7k30/z3zbrMCLE027YI5vjmRzM C9Gp1pY+vwJMTr900u6iT0+E2TkPQHEdwZBmiJR7Zne0+qOyAhnvOE/xeL7lk9bDIDbs 7Rwr/RFlKrv8aOcP6piiV2wS12yWHo/x+s5ck0VgqV9WxVTwszA7+gw8ChzSrUhDkcAW y8ucLRD0oseY7EwSOB8Bn+D9w9Hlr0hq7RAXW0/mGdEB8aHveLlHnHKuboM/o8Vb7TBu zp3Q== X-Gm-Message-State: AOAM531RgGNewCV2CGSE8wKI0numzDMqIvaAOqC2j5au2I3Tm6W559Oo nRmDLGwKSbP79B1cY8V608FcWekI1Wj0LdCa00s= X-Google-Smtp-Source: ABdhPJxGUZBBfmxks+iAEFmtTgt/Wjzl0KmJDjKRrAC0gaBWPCGHEAsFKNWw7ZZqj5Ufn6gZsd0UcTpwmn2DeOsDsRE= X-Received: by 2002:ac8:36b4:: with SMTP id a49mr9983461qtc.124.1598418774817; Tue, 25 Aug 2020 22:12:54 -0700 (PDT) MIME-Version: 1.0 References: <1598331582-19923-1-git-send-email-iamjoonsoo.kim@lge.com> In-Reply-To: From: Joonsoo Kim Date: Wed, 26 Aug 2020 14:12:44 +0900 Message-ID: Subject: Re: [PATCH for v5.9] mm/page_alloc: handle a missing case for memalloc_nocma_{save/restore} APIs To: Vlastimil Babka Cc: 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: D015A37604 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 25=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 6:43, V= lastimil Babka =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > On 8/25/20 6:59 AM, js1304@gmail.com wrote: > > From: Joonsoo Kim > > > > memalloc_nocma_{save/restore} APIs can be used to skip page allocation > > on CMA area, but, there is a missing case and the page on CMA area coul= d > > be allocated even if APIs are used. This patch handles this case to fix > > the potential issue. > > > > Missing case is an allocation from the pcplist. MIGRATE_MOVABLE pcplist > > could have the pages on CMA area so we need to skip it if ALLOC_CMA isn= 't > > specified. > > > > This patch implements this behaviour by checking allocated page from > > the pcplist rather than skipping an allocation from the pcplist entirel= y. > > Skipping the pcplist entirely would result in a mismatch between waterm= ark > > check and actual page allocation. > > Are you sure? I think a mismatch exists already. Pages can be on the pcpl= ist but > they are not considered as free in the watermark check. So passing waterm= ark > check means there should be also pages on free lists. So skipping pcplist= s would > be safe, no? You are right. > > 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 allocatio= n > > from the pcplist. > > Well it would be much simpler and won't affect most of allocations. Bette= r than > flushing pcplists IMHO. Hmm...Still, I'd prefer my approach. 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. 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. How about my reasoning? Thanks.