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.8 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 3FF9FC0044D for ; Thu, 12 Mar 2020 01:41:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2C7B220753 for ; Thu, 12 Mar 2020 01:41:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="goyBr3vT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C7B220753 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 6BFAE6B0003; Wed, 11 Mar 2020 21:41:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 670416B0006; Wed, 11 Mar 2020 21:41:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 585D26B0007; Wed, 11 Mar 2020 21:41:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 418A36B0003 for ; Wed, 11 Mar 2020 21:41:40 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 28B4C181AEF23 for ; Thu, 12 Mar 2020 01:41:40 +0000 (UTC) X-FDA: 76585008360.03.men94_2ba3e92ee7b46 X-HE-Tag: men94_2ba3e92ee7b46 X-Filterd-Recvd-Size: 5168 Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Thu, 12 Mar 2020 01:41:39 +0000 (UTC) Received: by mail-qk1-f196.google.com with SMTP id d8so4190497qka.2 for ; Wed, 11 Mar 2020 18:41:39 -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=nF5tqHstvUA30W4LSx4fCVSXA64TvPNEEL8r1P7taag=; b=goyBr3vTreoPre7Am+Z4s9hv82VQd0R5kunT8Sv6AMal/j74vgclsA/yQaaeOoBVyR OUBGqH1mvr56+9VtAqAH4xW1tjsdX+taJvZCWXimpHRcRTg8jQFxRxlFr88lwH++AUS/ AvHSWeNaWYQ+lj2X6v2DCypuHSt469HEy8r56wGgGVP9wxWutcmSIW3QjIbmq72uvcfn xIGBLHNwpjvk2QN3n8wAYoeeunBv6b+fT1ZfCmfKpVIngny711FQOGLsenn+kBbC9d5d E8HysjZA1CEPrLx/9a0oUDW6JE1WvRahvLmL/ssi46iO8mSYHFyK8KbLDZW4u9YNjmsm J6FA== 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=nF5tqHstvUA30W4LSx4fCVSXA64TvPNEEL8r1P7taag=; b=MviOcIOyl9u9uF/6uw8/ZNgN/kbTkozeQpDSXv28NvZyZdgMVT1Bu/CUoBhAMANz+9 o+yj8Ph+Idd5Uib44iSNyNOBzcTiK1rspcz+NCqiBdRcQCHnu9I6RVa+OtLdcEexNxz6 KGgsmp1PKUHVtQMRfBupnaeBIu79UdgrxOrmWs314OytYub02wVXduJcpkocxgoMBfVG Wn6gKzLfgXyDUEB7RNs17y1jg8wBisQL0hp0z+ccW9+YSW+bQOGLsyGzG/06fCCpRUEZ WyHhGsZizmhfoDm5SE+2jhTnttiUyyKUyNMN+F6O5Ubx5OEzGNy4vhCksX6NtKGr1NPz EBWQ== X-Gm-Message-State: ANhLgQ234xJgK0dF9/lT3RxwdATvKr1R9dHLk+TtcebqcVRinPfPM8np OL2TT9XSsK9bOuHT8Qsrx2O4kSJZbjWVQgxlGL4= X-Google-Smtp-Source: ADFU+vsSUTM7uycwkJRxMgl2aNE471s3inCBkW/jeII4Fkhf1HhYIbpK/48gHDTdXi2/24kn+94+ftqMZt6AFqvV7Q0= X-Received: by 2002:a37:546:: with SMTP id 67mr5362123qkf.272.1583977299116; Wed, 11 Mar 2020 18:41:39 -0700 (PDT) MIME-Version: 1.0 References: <20200306150102.3e77354b@imladris.surriel.com> <8e67d88f-3ec8-4795-35dc-47e3735e530e@suse.cz> <20200311173526.GH96999@carbon.dhcp.thefacebook.com> In-Reply-To: <20200311173526.GH96999@carbon.dhcp.thefacebook.com> From: Joonsoo Kim Date: Thu, 12 Mar 2020 10:41:28 +0900 Message-ID: Subject: Re: [PATCH] mm,page_alloc,cma: conditionally prefer cma pageblocks for movable allocations To: Roman Gushchin Cc: Vlastimil Babka , Rik van Riel , Andrew Morton , Linux Memory Management List , LKML , kernel-team@fb.com, Qian Cai , Mel Gorman , Anshuman Khandual , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, Roman. 2020=EB=85=84 3=EC=9B=94 12=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 2:35, R= oman Gushchin =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On Wed, Mar 11, 2020 at 09:51:07AM +0100, Vlastimil Babka wrote: > > On 3/6/20 9:01 PM, Rik van Riel wrote: > > > Posting this one for Roman so I can deal with any upstream feedback a= nd > > > create a v2 if needed, while scratching my head over the next piece o= f > > > this puzzle :) > > > > > > ---8<--- > > > > > > From: Roman Gushchin > > > > > > Currently a cma area is barely used by the page allocator because > > > it's used only as a fallback from movable, however kswapd tries > > > hard to make sure that the fallback path isn't used. > > > > Few years ago Joonsoo wanted to fix these kinds of weird MIGRATE_CMA co= rner > > cases by using ZONE_MOVABLE instead [1]. Unfortunately it was reverted = due to > > unresolved bugs. Perhaps the idea could be resurrected now? > > Hi Vlastimil! > > Thank you for this reminder! I actually looked at it and also asked Joons= oo in private > about the state of this patch(set). As I understand, Joonsoo plans to res= ubmit > it later this year. > > What Rik and I are suggesting seems to be much simpler, however it's perf= ectly > possible that Joonsoo's solution is preferable long-term. > > So if the proposed patch looks ok for now, I'd suggest to go with it and = return > to this question once we'll have a new version of ZONE_MOVABLE solution. Hmm... utilization is not the only matter for CMA user. The more important one is success guarantee of cma_alloc() and this patch would have a bad impact on = it. A few years ago, I have tested this kind of approach and found that increas= ing utilization increases cma_alloc() failure. Reason is that the page allocated with __GFP_MOVABLE, especially, by sb_bread(), is sometimes pinned by someone. Until now, cma memory isn't used much so this problem doesn't occur easily. However, with this patch, it would happen. Thanks.