Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2675333pxa; Mon, 24 Aug 2020 23:17:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyI42PNHcIgkBogzulKKNga05+CkRRLjKYT1AVyi/sUJKBk6KsLRviHdp4bqzQddB+r4085 X-Received: by 2002:a17:906:403:: with SMTP id d3mr8820402eja.522.1598336245346; Mon, 24 Aug 2020 23:17:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598336245; cv=none; d=google.com; s=arc-20160816; b=wKp+6wqK/cdIgGT6uqENpT5W5AbWL2LokRaOeQU0XvLkmbZ4381bNtFTcQF1l2sSOD k3A0HaTMlpDSJxAjCxXEofTwGngFwIpYfH/S3Bv+O5c+bExxBmWaM9RHWzKyibiyZYbn Quj61ZBpOKL/OXGC2xavPgrvb0TmPf/R0e8qYFLZ2on6L9rwEvJ9lK72azvEe6gL8ejn QpY3sj7fh/5LDlrOgBmnw+p3RR/CqV0iGGy5F6F0B4oNUhX8FEvm2jNeEFF1VIMmNu2q zEyZsTSn0EH18bh7uWBn4A0T67WyYmkyMla+s0hGcjhJuciLsuumNpgA1fIGfpJO/pZ/ LjKw== 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=drVWXY4OrHwvooutCydMRH+dz0kOVIaWYVFSu5MyClQ=; b=WAa5uQ0/Yr8/7njnfX4IUR8sd8wWaj5E5wOMAww7VdVM3SFEjXeyYc+OYzeJcSPZwy i7/7PWaHuBO4cvHJBhQj2x7oxGGYGqpMGfK3cgGQn0CUV6xzQFoBE/L9iCVQnoyToLBp NFuUBISgDIAvTl0y031CFO6g+BwfeZCZiX10Merh8b9O9AtQ435knuE4gA5NuLjHBJ6H YBf7yRBogLsxc575PX1s9iVzdIYEmHtcNfbWq6f7ryRaB1TMnEyfr2o4RlyROzucE5yc v0jBrt8dU3AA6f84sSYfMe5QdEsCKVR8R/9WYLOjP/rMmGp70+oNjiEDhuA+qBpVW9uk F6uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GghfrG7t; 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 f19si8283123eds.21.2020.08.24.23.17.01; Mon, 24 Aug 2020 23:17:25 -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=GghfrG7t; 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 S1728734AbgHYFeq (ORCPT + 99 others); Tue, 25 Aug 2020 01:34:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728598AbgHYFep (ORCPT ); Tue, 25 Aug 2020 01:34:45 -0400 Received: from mail-qv1-xf42.google.com (mail-qv1-xf42.google.com [IPv6:2607:f8b0:4864:20::f42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0CBDC061574 for ; Mon, 24 Aug 2020 22:34:44 -0700 (PDT) Received: by mail-qv1-xf42.google.com with SMTP id l13so4987601qvt.10 for ; Mon, 24 Aug 2020 22:34:44 -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=drVWXY4OrHwvooutCydMRH+dz0kOVIaWYVFSu5MyClQ=; b=GghfrG7tHpB+RtuXLrsxXCN5gdU7IRtRyzu9aLirLBUqHoPc3rTHz9Stl1m/Nx9ap5 Zrdq4fi9e7MkfPZzNKmKr0ljezPD3NLkhGr5wCtzxmB+LqITLs8fQq3erGQU6bKDKoyu owJxOO06fUOuMVEZGEjqOX+4/EpWaM0xHIfP1iRcOr0T1Iio4+cqc0LmtzwtaIDLzHl0 /xhHbgSbSBpbECob2ZJPyp5CR1UE7pZAIX1J52o7dT0bmCJnINsjvX+O7YvNWgm4HyiA /Nb1qND2RH/p8Io1SXaKlWejMswiVhJX5YIBocoRcITp7LGfR1BQgh+2ObMKuT64s7IN 3xeA== 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=drVWXY4OrHwvooutCydMRH+dz0kOVIaWYVFSu5MyClQ=; b=TgVpDqIUnikMLPQuOTHDGwS/Nj92gKOWydGpWSd2t6n1xbK+9+w1avFU2GxwRU7R09 kxRuyxBE++z5ON3VlRzh+q0SWbc/Qy85fqzN73k+a5bRb7kaN6m8QLGt85zoHO18pOhp 96EijAyzifLFYyHDBLXI2j/dI+sS+FU7FSKaHbVdJzjmZDKHHD30uuUYiOPB/BoRumdw sudyVgw/acmRxGWlrVHiTLflv6oOhXEAs1YTsj+bk4IE+TVjxbscIZeNkZ6fFD0FoS9H rr0wtDV8roBtvkgmAwoE/BjUd2N8RoRTokrXR0pNnfhfsZYbDmNYyzblWf/P5+sPmqbL mX4g== X-Gm-Message-State: AOAM533BbY5pUYwzOyDr6Ye7s9ACZf7QbJXQMZAEOHIvsihDaxK1b8TW gz7IyuY9LcaH2I8DwLLGgwIeg82JWnqAek+hWFpvD6BI X-Received: by 2002:a0c:ea8e:: with SMTP id d14mr7826970qvp.37.1598333683382; Mon, 24 Aug 2020 22:34:43 -0700 (PDT) MIME-Version: 1.0 References: <1598331582-19923-1-git-send-email-iamjoonsoo.kim@lge.com> <20200824221049.edb3c540bbfc859a6806600d@linux-foundation.org> In-Reply-To: <20200824221049.edb3c540bbfc859a6806600d@linux-foundation.org> From: Joonsoo Kim Date: Tue, 25 Aug 2020 14:34:32 +0900 Message-ID: Subject: Re: [PATCH for v5.9] mm/page_alloc: handle a missing case for memalloc_nocma_{save/restore} APIs To: Andrew Morton Cc: Linux Memory Management List , LKML , Michal Hocko , Vlastimil Babka , "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 25=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 2:10, A= ndrew Morton =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84= =B1: > > On Tue, 25 Aug 2020 13:59:42 +0900 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. And, it requires to break current cod= e > > 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. > > > > ... > > > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -3341,6 +3341,22 @@ static struct page *rmqueue_pcplist(struct zone = *preferred_zone, > > pcp =3D &this_cpu_ptr(zone->pageset)->pcp; > > list =3D &pcp->lists[migratetype]; > > page =3D __rmqueue_pcplist(zone, migratetype, alloc_flags, pcp, = list); > > +#ifdef CONFIG_CMA > > + if (page) { > > + int mt =3D get_pcppage_migratetype(page); > > + > > + /* > > + * pcp could have the pages on CMA area and we need to sk= ip it > > + * when !ALLOC_CMA. Free all pcplist and retry allocation= . > > + */ > > + if (is_migrate_cma(mt) && !(alloc_flags & ALLOC_CMA)) { > > + list_add(&page->lru, &pcp->lists[migratetype]); > > + pcp->count++; > > + free_pcppages_bulk(zone, pcp->count, pcp); > > + page =3D __rmqueue_pcplist(zone, migratetype, all= oc_flags, pcp, list); > > + } > > + } > > +#endif > > if (page) { > > __count_zid_vm_events(PGALLOC, page_zonenum(page), 1); > > zone_statistics(preferred_zone, zone); > > That's a bunch more code on a very hot path to serve an obscure feature > which has a single obscure callsite. > > Can we instead put the burden on that callsite rather than upon > everyone? For (dumb) example, teach __gup_longterm_locked() to put the > page back if it's CMA and go get another one? Hmm... Unfortunately, it cannot ensure that we eventually get the non-CMA p= age. I think that the only way to ensure it is to implement the functionality here. We can use 'unlikely' or 'static branch' to reduce the overhead for a really rare case but for now I have no idea how to completely remove the overhead. Thanks.