Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2769466pxa; Tue, 25 Aug 2020 02:45:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6PVPGyCFB0gwQ6Hr1Fkj9hvyqgW4EAVFj67ii7sBUFhBg7tbLqahO01xVj/Jj8e5kGP8G X-Received: by 2002:aa7:d8cc:: with SMTP id k12mr9502375eds.195.1598348733202; Tue, 25 Aug 2020 02:45:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598348733; cv=none; d=google.com; s=arc-20160816; b=RzODYc9TNELuJN7AjUtf9k06bl79Ycb6r4nUMDiUicA7RBDHc+GJzvWGoqv+AhWl+Y hoLrr6noIdkoMVF8KhCdbHJ7IiO6pW/i5RhPdqkld+MzCjZNEuAkSW/YgS+ZcB0Ch63l SzxQyFPyYMETu4X2bNZI89lsj1Otz1luNq9FPtISfg4K8QZMnxeEMCF48jkfI71XxC+c HSO6heP/61hfUUEHg7GLypOSXqrkwa8GnBghvsAsnBau2RtvF2qSOoi80Et6LOHmzTA9 1U0JshLPIo2YO55eDmZ7SZ2T0gY0I/3z4ZgmZj7S4g95ODbpmF+rx1fXz/+TcsJ9NGNc EfcA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Id0fl/dl65eSlCNi8qKy7By7RCSp0RKp7XQImG4qeFY=; b=SIzWd8Jybx8pej/QsOnyBFjWKr/TRu4Ly89ovi9ov/PhzhBhgP4a0h1EORFittaByc EIxPex/a1RnkFfNA3ZUqpNmXAfYAyUv/XoqPxDItJvRzSHyg9EVoS5aW2DXtHQee+XKE vtLRj6h4rrVBasNkBQ4pKrV8a0WGNY05MhUiZwTxNhnBRHOYQfQOkIsPqLm2wlsuMnrE DLDFVh/4LpE10L5cj2hzUvas+ptH8h53Dcvmty772YtBoPLB0sWR4p+oS9DRhEg+hC8l Ub4llzJ0gF3Ad0Krb4tt7rZmoVln5qrQktvMYqmp0aH/wE0FcAMWuE+a3DgtD8SpomGQ S1BA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bn6si4259034ejb.74.2020.08.25.02.45.09; Tue, 25 Aug 2020 02:45:33 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729534AbgHYJno (ORCPT + 99 others); Tue, 25 Aug 2020 05:43:44 -0400 Received: from mx2.suse.de ([195.135.220.15]:45586 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728059AbgHYJno (ORCPT ); Tue, 25 Aug 2020 05:43:44 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 92048AF33; Tue, 25 Aug 2020 09:44:12 +0000 (UTC) Subject: Re: [PATCH for v5.9] mm/page_alloc: handle a missing case for memalloc_nocma_{save/restore} APIs To: js1304@gmail.com, Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko , "Aneesh Kumar K . V" , kernel-team@lge.com, Joonsoo Kim References: <1598331582-19923-1-git-send-email-iamjoonsoo.kim@lge.com> From: Vlastimil Babka Message-ID: Date: Tue, 25 Aug 2020 11:43:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <1598331582-19923-1-git-send-email-iamjoonsoo.kim@lge.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 could > 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 entirely. > Skipping the pcplist entirely would result in a mismatch between watermark > check and actual page allocation. Are you sure? I think a mismatch exists already. Pages can be on the pcplist but they are not considered as free in the watermark check. So passing watermark check means there should be also pages on free lists. So skipping pcplists would be safe, no? > 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 allocation > from the pcplist. Well it would be much simpler and won't affect most of allocations. Better than flushing pcplists IMHO. Something like this? ----8<---- diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 0e2bab486fea..15787ffb1708 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3361,7 +3361,10 @@ struct page *rmqueue(struct zone *preferred_zone, unsigned long flags; struct page *page; - if (likely(order == 0)) { + if (likely(order == 0) && + (!IS_ENABLED(CONFIG_CMA) || + migratetype != MIGRATE_MOVABLE || + alloc_flags & ALLOC_CMA)) { page = rmqueue_pcplist(preferred_zone, zone, gfp_flags, migratetype, alloc_flags); goto out;