Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2076878ybt; Thu, 2 Jul 2020 23:37:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxc070xLBC+6KFz4lgkCTc84O1Dyfea7j32eMBQQ7pTVAeFU7hkZ91GW3HWk2tBPnTK2USD X-Received: by 2002:a17:906:6847:: with SMTP id a7mr30027909ejs.306.1593758233577; Thu, 02 Jul 2020 23:37:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593758233; cv=none; d=google.com; s=arc-20160816; b=0DYNNZMqnd+iSkSJ6BZPNUndhmrHlSTG8wkHfhe/HmKc88dKjOKbR9/0GI+b1u1gGB 8dD9njjZQP6VZF9/nSDHxraAxNjWFI6E6co0r9Ml+WN5a47TGn0qxeRG4cvtFaUPQLJu MEGsw5jvFjO/YxRETGebkbluJ13oIcCmXj0++Djt8i6/IpWhmvfFaJLuJ6wVjHVs1/zi jBcfEGUrlSOBBcOH7nNDJzF6oD9CTKXJZnJdFeARmmYqSNl1qHPZoNsfAG5thOjiilXw hSFg8chUGGUkypArK7BIuzcO9+e9WcJii5mL/jYfOnZd1I83kRjCkLa4yp/C1NRNq13k IiQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=u3qUOwsLsxiI6rED0QEYL5qR8wzRy0UEcKjWHFa8UvI=; b=y1gDRljGsMoydNtVQFm2W87JQb6iM7HsV7fZt/FVIPWp6Spo2t2P/eQ7Ys01SXHLb2 pPVfRYCmyPQo/uzd4ggoW93IokGKyoM+1JTcmESUueOwX1aMyRledx+GMGYFTSqntkgV JMgq3C9itE5ppO7+3AKmIC/ZYyY1wfRj5q0mce/3vkzw1WboP/UXKZT0WHCPaTjIpDIS Dtg1Qs2/ViLJAX4cAcLNo0wn9b0GPDJbsssQ9re7v4/facW/pss/Jooo5OLsl0hfFfbT WJiHTW4MQt4u3UCPjs5zeFITxAT9F9Ghk2zb51m7JgYGl4cpCMPc3DxBcG2TKi6JVeZf V6/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=j179t90F; 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 r11si7600713edw.359.2020.07.02.23.36.50; Thu, 02 Jul 2020 23:37:13 -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=j179t90F; 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 S1726053AbgGCGek (ORCPT + 99 others); Fri, 3 Jul 2020 02:34:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725764AbgGCGek (ORCPT ); Fri, 3 Jul 2020 02:34:40 -0400 Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6666AC08C5C1 for ; Thu, 2 Jul 2020 23:34:40 -0700 (PDT) Received: by mail-qt1-x843.google.com with SMTP id g13so23172976qtv.8 for ; Thu, 02 Jul 2020 23:34:40 -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; bh=u3qUOwsLsxiI6rED0QEYL5qR8wzRy0UEcKjWHFa8UvI=; b=j179t90FJYaHQ8HrtSupONgPsJoyTJ/0hYShVlyk5GgeN4gfTvp0PrqUpIGefV6oDd RmvOZIjjs5Kmax3U05y02v290UF7xB3UhruS01xuLJMEDTMomlsgJo3epZsHwwf8JBEG W535mzODdv7E0+RPlUcNGU6VnY5Wkl0xgbZ6/aTtP5LagZt4veLnACzgg3gJZnxHlPYM 66BLAfjbv68vHAazNY+f10Q7sbsiscMIAtGIvy4VIXJGDJ3wMT/EvajAdXMeFZeYP6FE yl0dvptsEmOYuGHG/nX3SRE/wW4aPIlSJ3OTAeabW1hVvrjGKwnvXRVfx+Z+LOLjbo4h ZUJw== 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; bh=u3qUOwsLsxiI6rED0QEYL5qR8wzRy0UEcKjWHFa8UvI=; b=pNl36TJN5fYdYwklPXc96OdojPINJUZC1/59kxVaAvKVekeSOtl0pk0EJH4BlvCYov /21ZsQPGEmiE3mjHAA94e8lvBb2yrJn5HR2S0Ud/tisOXPpGSlhz3B84f/zrTwDLpU20 T/NFafld417jPpz0O5soE27eXeIB7mJvtNwtZd/YQyi+9gH/1hOGoBzHAZHD1Am36gqm E/UQTY0LGwSmolNLvN1RwYyL1XmRqa7kJCWwCFdGiJ2leGsHziFi96uVC5NO4H08WYM1 Nm92SUIKUgpao2tjlGw364lvRz5n8S8e1oeQactLR5OaDAqWJj4w4XrcVPnC+KR4NbEa u11g== X-Gm-Message-State: AOAM530sHbYBgL49tZ/OrM/1214glsiRXDYQGbyF/FIy2MMX7VYRffEm /nhNCRkPAGkPb8OVC1ZhW/h566n8t269hTHRRRg= X-Received: by 2002:ac8:18b2:: with SMTP id s47mr21636760qtj.114.1593758079511; Thu, 02 Jul 2020 23:34:39 -0700 (PDT) MIME-Version: 1.0 References: <20200703061350.94474-1-songmuchun@bytedance.com> In-Reply-To: <20200703061350.94474-1-songmuchun@bytedance.com> From: Pekka Enberg Date: Fri, 3 Jul 2020 09:34:24 +0300 Message-ID: Subject: Re: [PATCH RESEND] mm/page_alloc: skip setting nodemask when we are in interrupt To: Muchun Song Cc: Andrew Morton , david@redhat.com, "linux-mm@kvack.org" , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 3, 2020 at 9:14 AM Muchun Song wrote: > > When we are in the interrupt context, it is irrelevant to the > current task context. If we use current task's mems_allowed, we > can fair to alloc pages in the fast path and fall back to slow > path memory allocation when the current node(which is the current > task mems_allowed) does not have enough memory to allocate. In > this case, it slows down the memory allocation speed of interrupt > context. So we can skip setting the nodemask to allow any node > to allocate memory, so that fast path allocation can success. > > Signed-off-by: Muchun Song > --- > mm/page_alloc.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index b48336e20bdcd..a6c36cd557d1d 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4726,10 +4726,12 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, unsigned int order, > > if (cpusets_enabled()) { > *alloc_mask |= __GFP_HARDWALL; > - if (!ac->nodemask) > - ac->nodemask = &cpuset_current_mems_allowed; > - else > + if (!ac->nodemask) { > + if (!in_interrupt()) > + ac->nodemask = &cpuset_current_mems_allowed; If !ac->nodemask and in_interrupt() the ALLOC_CPUSET flag is not set, which by-passes the __cpuset_zone_allowed() check for allocations. This works fine because in the case if in_interrupt() the function allows allocation on any zone/node. > + } else { > *alloc_flags |= ALLOC_CPUSET; > + } > } However, if you write the condition as follows: if (cpusets_enabled()) { *alloc_mask |= __GFP_HARDWALL; if (!in_interrupt() && !ac->nodemask) ac->nodemask = &cpuset_current_mems_allowed; else *alloc_flags |= ALLOC_CPUSET; } then the code is future-proof in case of __cpuset_zone_allowed() is one day extended to support IRQ context too (it probably should eventually respect IRQ SMP affinity). > > fs_reclaim_acquire(gfp_mask); > -- > 2.11.0 > >