Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp812285pxa; Thu, 27 Aug 2020 16:59:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxzTE9dOVGuPZYRfzBz99OBY59rv3ejVsmKVVuV/FrLvr66i2dlx6WcTp4lX5wuR3czin4N X-Received: by 2002:a17:906:5811:: with SMTP id m17mr23086226ejq.40.1598572745384; Thu, 27 Aug 2020 16:59:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598572745; cv=none; d=google.com; s=arc-20160816; b=jHJa3Cw4tLaTB71nhP6R8pjXJhN00km0uwlzjaeOdIPLRNyYcQiPln0HrcBF00zjbT 0sAqZIsI+mh5IvNPnX+CB03zL/I5A0KDSRDMl62MfQLCM38F4ppIx3XQvYVa91OqXhnM 0wcjkhJtB68eUglslR0JWD4Xz+ZexXHz3+6IMy4Ts/I2Bs9xnK7tp8JXqNYH1DKaovYG XMMrQ6iP0hDgWpJLp2FyZcQze6CmS7zX7n8uqwYGqQwdVE82mtPcvG6uWIhrstOrD4NB BTN/OsJNjs2lYn8TKOG9ivTLgRKiF7IoklfNaBDvkOE66O2hpwMMe/zvwZjBobBqhqmI 9Ayg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=tPhhvVGwKSAuel8jNNMpBV2hW2oRk0ci2Ch7jocIK7o=; b=wq63ACublre1HCuLpxcmHaRJtCZPmgx8C/MRKTZdhOJQ77Zg+c5undmYWxBsE28CAs wx9XZJFwsJljhg2wsyy6WpnJOspuQxx2gqnxMi9dsJhsMubwlVo8DqnU9H3r17mfc1/M UAwTfmv0n/KrHxjFKV7o3XwIyFbv9LX4kpIrDmDaTyrgxoO6Wzkxvf5LYdfjYyIlC2Ek TzF4KrB/vy21aWnLhrA5zIs9ecc+47GLup0tGtvG3qOvcHssCk1EbR06xrvetRrgkCDl swW3WsafQNstTXDAAdwIaSI6JJnJAch2iwBzx/odV8sTY4P+flH9+Knjlfx8ZMmBU22F YIIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="QwDD//o7"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h8si2510867edw.611.2020.08.27.16.58.41; Thu, 27 Aug 2020 16:59:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="QwDD//o7"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727926AbgH0Xy6 (ORCPT + 99 others); Thu, 27 Aug 2020 19:54:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726147AbgH0Xy5 (ORCPT ); Thu, 27 Aug 2020 19:54:57 -0400 Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABBE2C061264 for ; Thu, 27 Aug 2020 16:54:56 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id u3so7836800qkd.9 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=fVqsrQx5rbrE5HjcFHwbeRTOdjnAoRWg59zPs2EUTpfQG0vbze0jnggqhzcEtaGTcd AS8HLVAizlHjO++Fl/CUGsJgsZ4FF0Ro+S1n4FKQiyMq1XmYbkhpoXqv150ZXifk3znW ftGeUBr8mFinI13fPm3u2opEdrE1dQoOeGvBhgXhST90ukaCAjPUsyjlQFx902tb6c70 pH8H+yST0FAY/VOYFT34gKyB+cKiuyMxNI2fLz8/4SmPlF164rg5eJDl3pnXxMhi7YFE yDiv2hOMPeFUQ7ps0kvhe7im67hdUcblsX8r8DS+AHSN+pi1rCIxrD1qf18nzyimpNYM Xh4g== X-Gm-Message-State: AOAM532PoQOoDAMDW6lIG/sRCVxEm6eQYpANy/RB2L6zqhd1Fmf87D6r dVyzbm7Udq4sVW/f84/DEx+GG0eHkTScXyn3zfk= 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.