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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DAC22C3DA4A for ; Thu, 22 Aug 2024 03:15:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4183C940014; Wed, 21 Aug 2024 23:15:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C71D94000B; Wed, 21 Aug 2024 23:15:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 267E8940014; Wed, 21 Aug 2024 23:15:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 076A894000B for ; Wed, 21 Aug 2024 23:15:53 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9F2981411B0 for ; Thu, 22 Aug 2024 03:15:52 +0000 (UTC) X-FDA: 82478416944.24.C6706FB Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf24.hostedemail.com (Postfix) with ESMTP id 2DAD8180004 for ; Thu, 22 Aug 2024 03:15:48 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=WtM+LZbN; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf24.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724296461; h=from:from:sender: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:dkim-signature; bh=vM0VGpc++28VKep3l7Qp8XNykaCbGwjKhJqn2A5lERM=; b=612usV9syGQxlj6gOIkHdLII0p0myrwU+R3V2sVWSFzq7FnwdjIRlhvLXYa1OyJI8/qJGr ZdSQQPfSaw0R2ywfSJov4aB0Er4HCSSAph+LFbhKn2R1VWp40sDBEaT3U2kPaStad0m99w rHq5dmgW2liLH+a00IiMzAOdisdNzBw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724296461; a=rsa-sha256; cv=none; b=MjMT8A91fvbWsiOQhCR8L4SPNE+iYMgEzlJVpNSkdxLNBhcEu5yTnKtIckyEqFkUKb96Ek BR6CWpxYBFbZ9+SwVZuu/inBHMNxwFdb3qdlg0kPFDvktoC47AP0A7EsKD7BKSu9THyqRq d4XX9A96dKrE6HrpQNbu+LkhkI9MvR8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=WtM+LZbN; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf24.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2f16767830dso2780651fa.0 for ; Wed, 21 Aug 2024 20:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1724296547; x=1724901347; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vM0VGpc++28VKep3l7Qp8XNykaCbGwjKhJqn2A5lERM=; b=WtM+LZbNt2NmtX7JS87FupnObgCxA6WwfPc4BLMt9FrYd+yGlHPDaOXIvWhP1D9p4u JWi5qEdf5JRGoGYUi9gOrqBku97raTiPowWqDTzL/k5npmfgvRFbemNQ67Alj+r/l3i3 G3O0aJtPPtG6F8OyYTtxHMGQ11ha8GlV6AJM5hrBx9deimENMmKh8oLzQHlEXQZJo3sI eDQNZir6UtfTn+iPjxPstENKyXnOwNar71gBiNK5/zXSkJFwJlyCkmdX3sIHtlxasBqO sVHUw2Bcz7N6Ao73KiNTtLQYTxFiuYuHqakkT4vOUgvJkerlT9hKm7SDV3I/o3Y0oSQE dhCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724296547; x=1724901347; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vM0VGpc++28VKep3l7Qp8XNykaCbGwjKhJqn2A5lERM=; b=vNMA4tl+/iVooeFOdT7yT1EPoy2hL0e8IrgPGkcRH7TcBPn5CrrSltuaNyG+/nYAZG kGJmlUDgTSIITRMoTqvAjVH/6gHTHdhXCpWGOQ7WIo51Nni9C8kTm5CUNIbNcFkIZ99X t9xDFwGFKzhb8ctS80Yyr9DN2OTEJ3HL2SKlf0WUo/4C6DkLNY49tGSFO+hjm8kWnnjF VLCZuZFMgXPN60FO0QPaAiQqKu3R5q1lj1emMr73pyBlZajvDhaF+ipxfuhaZcjiYBKF nzW2iOCdN0Hpp1yxwcfaca5XgSpmznncu7/F8ZgX9iGPCr3tk3PcomzJiwCcLBPfRdUx Woug== X-Forwarded-Encrypted: i=1; AJvYcCVMsPzjUoXHWKEKNk20bEu4klD0pa50x/Uv8EI5CEA9w004AAiIBOvz1tf/kDu/NHarTJlQTMo9Pw==@kvack.org X-Gm-Message-State: AOJu0Yw7yMI4YsTUFQaWJbiTwJ37hLXHLNGfrxGCROHB1EA+g3p4nVa4 mT5ymBrOrLnu5TMS4vudmDITtdOh5JMF09nMd2OMDfA7SrYNfzGTdPAO75+9jtTkyYQEnozOLk4 SFM6Md2yIdEzxxV70cLqO5Z+dfRLUYYzAz0HTjA== X-Google-Smtp-Source: AGHT+IFKMin858I+mlpUJ2KUlld1JnHNrWMfMMDwzAXDgaD3Y3Bol8k2HnoTudZ0gvsdR1zYtwXSOO+zsHSxp8wBkpI= X-Received: by 2002:a2e:a589:0:b0:2f1:59ed:87ab with SMTP id 38308e7fff4ca-2f3f88ea892mr26771881fa.24.1724296546876; Wed, 21 Aug 2024 20:15:46 -0700 (PDT) MIME-Version: 1.0 References: <20240821135900.2199983-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Thu, 22 Aug 2024 11:15:34 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm:page_alloc: fix the NULL ac->nodemask in __alloc_pages_slowpath() To: Michal Hocko Cc: akpm@linux-foundation.org, mgorman@techsingularity.net, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, lizefan.x@bytedance.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 2DAD8180004 X-Stat-Signature: qaj8576jwms8rta6dtzzwo4cfmnmg8i5 X-Rspam-User: X-HE-Tag: 1724296548-650425 X-HE-Meta: U2FsdGVkX1/lYpEntdMy+OVzkGPui8OSVu0wABDWSEdEnkbWoe94q3OJAjN+LxXi6Cy7LhX/ALw90yZ6WyOnKJbWBxeYu+XwRg4Exzg3rQPiVCHnBjaTAiIRzVBFQJLJ/s1JDh0zac7Hds8GltqO0IIqsig5iczM1py0Z/rXaSFtgBx5sPYhpkK6hZvrm4zKWOEof6K9KgTWQZ6zKkNMi+b7TRcsZNgvfclMYlGvX+qkxt/a0XO4Mz5Na8jBKi2yLE4rCsdeOa1eCBtrQxRx1mV61tXXzm390OS3Km/uxOGjTNs2sCwFgwaCFLywhgpwr7Okr5WWZZ1q939BfMRcQ+d/ScVPVUYAE1aMG+DTaCo8HWiytaKEVTS5dX97Ldhq8ozZci8sv6h//pX8BZjWBz7tGJyigKva/j26KNnTUrmH0MT/ew07/+EAkl6vijMQ7tCMm5RpmyrBruFWRQY9pdn+Eu6mC/AwErKN/ZzwEA0BWbcdl1gNcpIZ8xv8b4SC7WmENLfJXK5F8Xq3T99yPcrTc9k3iwUoHE4FfDbNgd6e89sPIBQ7RPyO9TNWp02Z9GdXZjCHMyn6IERwPSMs3viwuqstNvgeynvSeCaZkWdxeJpLCYPyXsLV+JSSdgcppid42GL8MT8yXnjurtATxLpwIdnYVIOUAz5TmB1Gs3dMwcLGlIMSIbZ0K3NjUnw2uAeb9XqZl3Mi3zKAtbV15D4w6ayXJBcdjZm1ZfMfefd5ZPkQ6+ztkVjAyCjouUJUXN7Y2eAjG6mFdTkhox0q7nMc3i0YRq3eLNZ10LtOsccT3haxNEPTvYOfrvK1XPYlEvcgiLybT0oWbMsILnrK8psM6gWQKmS4d7EamoHIKa+qt2bpu2V2s6IEtOpW+hi99sfGxC2tFV5S9tex5hobuSiSenEuJYPvB9P5mCg9VaPHrOCt5DqUN99cA1V72QRx/wAhpV7tiYi41J6rgbH X158zLpu yXUHy5L6JMQFozgB7sakKF7qgb4SWedzur4ykE8OM5ZO8/C/Q+RflotDo9hU8sgPC3UxME8QhRKQZ6BAV/2HaApgh1RaIU3jsZJp2gbhbanPFL5EDJsIn/VEn3f++JEQBhOEQ0qV0gh4cTG3FGJ12JQ3mC8IIRIGZjTsaCHRqCTQ9ENUr9yzuzIwnp06dz4sZMdD1WXt4d4GKvfreu/8/fnukMVHMVixXWg/RRvz4QwahYjxCE0HhEswNNnNkgfz84iHAaCecnPnuD3m3qFAeOHu0MqZy+b3QnOt5 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Aug 21, 2024 at 11:00=E2=80=AFPM Michal Hocko wro= te: > > On Wed 21-08-24 21:59:00, Zhongkun He wrote: > > I found a problem in my test machine that should_reclaim_retry() do > > not get the right node if i set the cpuset.mems > > > > 1.Test step and the machines. > > ------------ > > root@vm:/sys/fs/cgroup/test# numactl -H | grep size > > node 0 size: 9477 MB > > node 1 size: 10079 MB > > node 2 size: 10079 MB > > node 3 size: 10078 MB > > > > root@vm:/sys/fs/cgroup/test# cat cpuset.mems > > 2 > > > > root@vm:/sys/fs/cgroup/test# stress --vm 1 --vm-bytes 12g --vm-keep > > stress: info: [33430] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd > > stress: FAIL: [33430] (425) <-- worker 33431 got signal 9 > > stress: WARN: [33430] (427) now reaping child worker processes > > stress: FAIL: [33430] (461) failed run completed in 2s > > OK, so the test gets killed as expected. > > > 2. reclaim_retry_zone info: > > > > We can only alloc pages from node=3D2, but the reclaim_retry_zone is > > node=3D0 and return true. > > > > root@vm:/sys/kernel/debug/tracing# cat trace > > stress-33431 [001] ..... 13223.617311: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D1 wmark_check=3D1 > > stress-33431 [001] ..... 13223.617682: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D2 wmark_check=3D1 > > stress-33431 [001] ..... 13223.618103: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D3 wmark_check=3D1 > > stress-33431 [001] ..... 13223.618454: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D4 wmark_check=3D1 > > stress-33431 [001] ..... 13223.618770: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D5 wmark_check=3D1 > > stress-33431 [001] ..... 13223.619150: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D6 wmark_check=3D1 > > stress-33431 [001] ..... 13223.619510: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D7 wmark_check=3D1 > > stress-33431 [001] ..... 13223.619850: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D8 wmark_check=3D1 > > stress-33431 [001] ..... 13223.620171: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D9 wmark_check=3D1 > > stress-33431 [001] ..... 13223.620533: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D10 wmark_check=3D1 > > stress-33431 [001] ..... 13223.620894: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D11 wmark_check=3D1 > > stress-33431 [001] ..... 13223.621224: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D12 wmark_check=3D1 > > stress-33431 [001] ..... 13223.621551: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D13 wmark_check=3D1 > > stress-33431 [001] ..... 13223.621847: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D14 wmark_check=3D1 > > stress-33431 [001] ..... 13223.622200: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D15 wmark_check=3D1 > > stress-33431 [001] ..... 13223.622580: reclaim_retry_zone: node=3D0 z= one=3DNormal order=3D0 reclaimable=3D4260 available=3D1772019 min_wmark= =3D5962 no_progress_loops=3D16 wmark_check=3D1 > > Are you suggesting that the problem is that should_reclaim_retry is > iterating nodes which are not allowed by cpusets and that makes the > retry loop happening more than unnecessary? Yes, exactly. > > Is there any reason why you haven't done the same that the page > allocator does in this case? > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 28f80daf5c04..cbf09c0e3b8a 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4098,6 +4098,11 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned orde= r, > unsigned long min_wmark =3D min_wmark_pages(zone); > bool wmark; > > + if (cpusets_enabled() && > + (alloc_flags & ALLOC_CPUSET) && > + !__cpuset_zone_allowed(zone, gfp_mask)) > + continue; > + > available =3D reclaimable =3D zone_reclaimable_pages(zone= ); > available +=3D zone_page_state_snapshot(zone, NR_FREE_PAG= ES); > That was my original version, but I found that the problem exists in other places. Please see the function flow below. __alloc_pages_slowpath: get_page_from_freelist __cpuset_zone_allowed /* check the node */ __alloc_pages_direct_reclaim shrink_zones cpuset_zone_allowed=EF=BC=88=EF=BC=89/* check the node */ __alloc_pages_direct_compact try_to_compact_pages /* do not check the cpuset_zone_allowed=EF=BC=88=EF=BC=89*/ should_reclaim_retry /* do not check the cpuset_zone_allowed=EF=BC=88=EF=BC=89*/ should_compact_retry compaction_zonelist_suitable /* do not check the cpuset_zone_allowed=EF=BC=88=EF=BC=89*/ Should we add __cpuset_zone_allowed() checks in the three functions listed above, or should we set the nodemask in __alloc_pages_slowpath() if it is empty and the request comes from user space? Adding checks respectively in the three functions might be safer and easier to review. It would be better if you had any suggestions. Thanks. > -- > Michal Hocko > SUSE Labs