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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41BB3EE4996 for ; Tue, 22 Aug 2023 06:32:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232502AbjHVGcG (ORCPT ); Tue, 22 Aug 2023 02:32:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233027AbjHVGcA (ORCPT ); Tue, 22 Aug 2023 02:32:00 -0400 X-Greylist: delayed 97042 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 21 Aug 2023 23:31:51 PDT Received: from out-22.mta0.migadu.com (out-22.mta0.migadu.com [91.218.175.22]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CC8E1A1 for ; Mon, 21 Aug 2023 23:31:51 -0700 (PDT) Message-ID: <3ac6b49e-f605-6f8f-ba22-a411269cb818@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1692685909; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PkmheFjFxExaCu9L5a48Fws0uehvzL2G5MIM97l1kY8=; b=QMPCPA7FLfHqCiIiLXVPW69lDGE0fSXD2eJYvbjXmXmsgFpE/SjABJKQ/WbI6jyP0vVU8P QOGjpKqk+XX2DeE0jyNCysjqWaFWXWicyMZJZNtpMuoMcDIBQmB4q0Lp76NINGsMS2M+Pm 15JKLKEgl8zodMWAv3PMCxJ8/bcy5tc= Date: Tue, 22 Aug 2023 14:31:41 +0800 MIME-Version: 1.0 Subject: Re: [PATCH v4] mm: oom: introduce cpuset oom Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Gang Li To: Michal Hocko , Waiman Long Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, rientjes@google.com, Zefan Li , linux-kernel@vger.kernel.org, gang.li@linux.dev References: <20230411065816.9798-1-ligang.bdlg@bytedance.com> <9ba0de31-b9b8-fb10-011e-b24e9dba5ccd@linux.dev> In-Reply-To: <9ba0de31-b9b8-fb10-011e-b24e9dba5ccd@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2023/8/17 16:40, Gang Li wrote: > On 2023/4/11 22:36, Michal Hocko wrote: >> I believe it still wouldn't hurt to be more specific here. >> CONSTRAINT_CPUSET is rather obscure. Looking at this just makes my head >> spin. >>          /* Check this allocation failure is caused by cpuset's wall >> function */ >>          for_each_zone_zonelist_nodemask(zone, z, oc->zonelist, >>                          highest_zoneidx, oc->nodemask) >>                  if (!cpuset_zone_allowed(zone, oc->gfp_mask)) >>                          cpuset_limited = true; >> > Does this even work properly and why? prepare_alloc_pages sets >> oc->nodemask to current->mems_allowed but the above gives us >> cpuset_limited only if there is at least one zone/node that is not >> oc->nodemask compatible. So it seems like this wouldn't ever get set >> unless oc->nodemask got reset somewhere. This is a maze indeed.Is there > > In __alloc_pages: > ``` > /* >  * Restore the original nodemask if it was potentially replaced with >  * &cpuset_current_mems_allowed to optimize the fast-path attempt. >  */ > ac.nodemask = nodemask; > page = __alloc_pages_slowpath(alloc_gfp, order, &ac); > > ``` > > __alloc_pages set ac.nodemask back to mempolicy before call > __alloc_pages_slowpath. > > >> any reason why we cannot rely on __GFP_HARWALL here? Or should we > > In prepare_alloc_pages: > ``` > if (cpusets_enabled()) { >     *alloc_gfp |= __GFP_HARDWALL; >     ... > } > ``` > > Since __GFP_HARDWALL is set as long as cpuset is enabled, I think we can > use it to determine if we are under the constraint of CPUSET. > We have two nodemasks: one from the parameters of __alloc_pages and another from cpuset. If the node allowed by the parameters of __alloc_pages is not allowed by cpuset, it means that this page allocation is constrained by cpuset, and thus CONSTRAINT_CPUSET can be returned. I guess this piece of code is reasonable and we can keep the code as it is. Thanks, Gang Li.