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 46971C71155 for ; Mon, 16 Jun 2025 14:17:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE39C6B0089; Mon, 16 Jun 2025 10:17:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBC626B00C9; Mon, 16 Jun 2025 10:17:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C834F6B00CA; Mon, 16 Jun 2025 10:17:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B1AF36B0089 for ; Mon, 16 Jun 2025 10:17:10 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 73EA91204C3 for ; Mon, 16 Jun 2025 14:17:10 +0000 (UTC) X-FDA: 83561465820.25.465340E Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf21.hostedemail.com (Postfix) with ESMTP id 9233F1C0009 for ; Mon, 16 Jun 2025 14:17:08 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=R4NbRM9X; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of bijan311@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=bijan311@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750083428; 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=eP6PuM+64K5CWtrRCBbwXKZnsU5mxw6QkvsFbixFqYU=; b=mygYgFuUm/OSLQsSzjiTpS1Bu0HXSqewk+akFtLfI39+o2E0jfF7GYZakwRQtMu5ted1pX /0fdRura52dgn5SLHXZy4hzgIxPX/M0rEJssqTTIwvgQcTZWYU33GurEE/QkQEoHRA9s2H miLbrarUnkc+ApoMIrkVbzkTdwPbV9k= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=R4NbRM9X; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of bijan311@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=bijan311@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750083428; a=rsa-sha256; cv=none; b=nmhaaRv7MqVSBiT6u3WiEUgTr74Nhn16yVn429+c2DoGYMOFegHuBLMwADg66WA8jqZHDA RRqIQynmTc0CQoLhyyjID1MpXkQKm8N6uUbVHa3T2ct1uXrPZuA3upCo+1ijlKxQSP0Z9R BPUHVRpjTT0JwgHJHVSaFuobtkp/Z44= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-ade58ef47c0so952382566b.1 for ; Mon, 16 Jun 2025 07:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750083427; x=1750688227; 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=eP6PuM+64K5CWtrRCBbwXKZnsU5mxw6QkvsFbixFqYU=; b=R4NbRM9X+YWWU/DiO8a64O5n4cwGnMBbYzffdZfk0zY/PBt6N6TEXuFdiALOEUfeO7 1k2J1b5MDCz1aBHZHk+g073tNfmce2ctt5yvawE/bgubtMtMKeidMHPuIOCQ6Su2MpEI PH90vEIF1c+LMzEj+V9IU0gS8zlK30+YasW1nTQxa2Lmu9J8NzA1UxkAe0Gj2sxrqcHP XFE4WIr7pulV1DBg8Ib5Vgxl3TAVJU30dnD54PmEdJfov5SIl3gvxcaGgQYMFp1Iss1s yYurxXcJln3EzdopNSC80OISXXH8E0FmlkM3XlRKYu7+D2FsN28u7polEGTAD45QIJJM KVgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750083427; x=1750688227; 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=eP6PuM+64K5CWtrRCBbwXKZnsU5mxw6QkvsFbixFqYU=; b=JZnCbc6iT5jGbSQpgTe5IN4J+5Xvl9DFFAYebznmOukjju7hk8TrZu5hjcKL13iENH BpSuIj5HEfvTczjzbNL/XnhjjjgvsWKEmh4GHsk5QjVu9PNRJHQIohXVnD6PFQfLz6KI KnB09ZwyK+ituxZhRXfm1hSpU0kaQf1trOmdlyrccS0Ra8FWZTr5FqHrR0ZT0PZBoGCV 2NbdtX3wBYO1LKeL3jeBPWCMO3KnpvUIG59PEdQRL5JI1G5Smq6B0PMX56UblQpnx9BZ RNXPRn4n8/ZmWLW9W1ctd7SXRGcvAQ5/kOPuUeoA3D6YSwao2RJsBf2umegpx2qU2IZW LlFg== X-Gm-Message-State: AOJu0YzIhk2SfEyqN/qLnbu4VD7NM6/JrSnBMfqBFKbGagi47F5uFXz7 V3NQOK2idKo0G/r1rqURFjZwQhfqeJcGGDkp1AVZjOVac1DKr2O5bf8Jv/eeIRc9Cje4GNKlOb2 rEFWUBaNx2Ip1WISrNWsl0MFX99sqfnbentcZ5ViK6w== X-Gm-Gg: ASbGnctEZbK/HeEU/XRAiueNOYkyuzpSdN+soxg+F/mTbLv53YV8NkDSZ6JE5q6C3qj jsMFJRaX23++3c4caUJIj+XMy5FsS6J4TzfRb/keolkt4+OCAxYKSRtkyRh7c2hYVp+I/G5Thvr Xw5HMdoPN7iiAo1gTUWvyXfRl7/eNwL1PA6FeEg73fOCtLtOh/Axv9QLohAW7NTL76bYRMsuujf eXmkA== X-Google-Smtp-Source: AGHT+IG36AYu/aqp41xnF1pJkXFnqEk2HCgmA8jDS9zdCLJ74WU28G5N0cZpsN3g7yXaxRPiI8ZvSI/MMogdMmVSBfg= X-Received: by 2002:a17:906:9fc5:b0:ad8:6dc0:6a8a with SMTP id a640c23a62f3a-adf9bfdd52fmr854559366b.1.1750083426656; Mon, 16 Jun 2025 07:17:06 -0700 (PDT) MIME-Version: 1.0 References: <20250612181330.31236-1-bijan311@gmail.com> <20250612181330.31236-2-bijan311@gmail.com> <5a50eeba-b26d-4913-8016-45278608a1ee@redhat.com> In-Reply-To: From: Bijan Tabatabai Date: Mon, 16 Jun 2025 09:16:55 -0500 X-Gm-Features: AX0GCFtYGWGWkDqtRWR9qfiUop7Yc8zxOn5BNjJ8enw3Dihp3CCnDxICYmQLo6k Message-ID: Subject: Re: [RFC PATCH 1/4] mm/mempolicy: Expose policy_nodemask() in include/linux/mempolicy.h To: David Hildenbrand Cc: linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, sj@kernel.org, akpm@linux-foundation.org, corbet@lwn.net, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, bijantabatab@micron.com, venkataravis@micron.com, emirakhur@micron.com, ajayjoshi@micron.com, vtavarespetr@micron.com, damon@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9233F1C0009 X-Stat-Signature: z1bpcfudk3ebwyo5khc899s6oewunkd8 X-Rspam-User: X-HE-Tag: 1750083428-960178 X-HE-Meta: U2FsdGVkX186dK3ikcaziFhcWLsmWiG/I84Hbtx9te91shs/8DiCFh2ZdjHRT8Dm5zpVm2HjZkKyzjomBO0zgmL2yceM7FFm5aTRzEzlFFSNChb0fr7ZALQUuGx6pqv460N4eH85N5Ytkp7CsWMB8XJzJXezRY2jndDSjEYYBr34Rk1lWfqBMn6/2GyoZb5yl59UcEB7x8mMS95n+lSpwGEgxf9l84jUQN3qNuGCNL5tgMc2IpW2+At16k0EdNejQYsZoPtmc34TtUS+fK++NB5cVIvJwKyHh72AsjjxT6WpNmOCsaAOYGB9yvfqbe1aT+2wQqNGk2CzwAoyQQmcA1ykfiVa/XLb4iPw1eq/hOKlzAvQMa8BbrZjrbmiai0SyLdIUpRXw2plzVq8vOQyumwkokmYmmgGoLbuxLTtK7iLGyrtvujPoUqCfVGCcyMVfnW07ZZQFeXBuWok7EtXPFYZ7ydNTotwv+CFeI22t2hiOQOK0tHhBzJSXgGlxXrlWF8D46La6K0Jf9jtvekGL3XWferUvBFfK7dM7SOdqMDGlzoX9bS/s+53hqTuP1LqCHOv4CzHtV9TdUzrFcx8z2bogFoYCfCVV6ZC2PP7AbrxwXxTa/xuXKIXdFGQLYKj8tnbOEd7dF784f9SaiuP4akI+WFKe0Q36FIey8gSNyIEo++9Nyi/O2GQB3vJJr9o76UQw3i9oEQ0hDEt3offqfKpE5WpxQ/ptnx4kVcp6M06Gt+VDAvVUbZv/ix+CV9MJ2j66YDFIU6hcrfsFu51b5Am/Je7o+BRh8F9tAJFgxne/0KI36Etp/S16xnAkStuf9P6yo/4ClHjJ4gCSpsGtemlc23vsu4CfFcn3koWXyCyr2flBGGeiePyBzx85i26aeu8F5wfBFAwbSvbbcZKYwCH/p7xS3e1BZ9VSLnh31Hv+me4BLKFquZfA154yeNT2PCsO8Q0xAMZ4yHbKep bsm8CZlp mVwSWQcasYs6ZCBpry9XuJhLzRU4NV5Nn/ARDe7DpX/5/vKgl4ck3vsVHQhgS4kUX2HqcX/lVyU4AVZe2KKYZCZrGqxGuKNdWkPGq8KcFEuFyMtPf0DNx9VkeJ9AgyQ0zMJbJSM58rzb60550AkU2yqQPhEdZAk7Dw0/vE5lyupwbQCBzbcgGNs9xBKtym09wzElJns7tL7gC32ky9Cqoe56PNJIAc3E7s+wM0b4SsUstzffKylDrKCojo7275hF9i9RA7CIQ/Xz+8Yq1VNjTA5nIHh0z56FI5vfiOasFdm2Sti+ZaWaQfJNNZ6qswEQAhZzi3ccYDLqXBa7IkFa51BMQID7BKCXfTgEoEOPpARVISJ7gah739x0gQW2kjkiLNPpSSPCld7V4xh8wuLLgUJIa6CKdUMAbiX5iCKulleCnjtayObBxaqKBmx8o5LraEe5re/M7dN7texI= 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 Mon, Jun 16, 2025 at 4:46=E2=80=AFAM David Hildenbrand wrote: > > On 13.06.25 18:33, Bijan Tabatabai wrote: > > On Fri, Jun 13, 2025 at 8:45=E2=80=AFAM David Hildenbrand wrote: > >> > >> On 12.06.25 20:13, Bijan Tabatabai wrote: [...] > Hi, > > > > > I did not use get_vma_policy or mpol_misplaced, which I believe is the > > closest function that exists for what I want in this patch, because > > those functions > > I think what you mean is, that you are performing an rmap walk. But > there, you do have a VMA + MM available (stable). > > > seem to assume they are called inside of the task that the folio/vma > > is mapped to. > > But, we do have a VMA at hand, so why would we want to ignore any set > policy? (I think VMA policies so far only apply to shmem, but still). > > I really think you want to use get_vma_policy() instead of the task polic= y. Sorry, I think I misunderstood you before. You are right, we should consider the VMA policy before using the task policy. I will do this in the next revision. > > > More specifically, mpol_misplaced assumes it is being called within a > > page fault. > > This doesn't work for us, because we call it inside of a kdamond proces= s. > > Right. > > But it uses the vmf only for ... > > 1) Obtaining the VMA > 2) Sanity-checking that the ptlock is held. > > Which, you also have during the rmap walk. There is another subtle dependency in get_vma_policy. It first checks if a VMA policy exists, and if it doesn't, it uses the task policy of the current task, which doesn't make sense when called by a kdamond thread. However, I don't think this will change what seems to be our consensus of adding a new helper function. > > So what about factoring out that handling from mpol_misplaced(), having > another function where you pass the VMA instead of the vmf? > > > > > I would be open to adding a new function that takes in a folio, vma, > > address, and > > task_struct and returns the nid the folio should be placed on. It could= possibly > > be implemented as a function internal to mpol_misplaced because the two= would > > be very similar. > > Good, you had the same thought :) > > > > > How would you propose we handle MPOL_BIND and MPOL_PREFFERED_MANY > > in this function? mpol_misplaced chooses a nid based on the node and > > cpu the fault > > occurred on, which we wouldn't have in a kdamond context. The two optio= ns I see > > are either: > > 1. return the nid of the first node in the policy's nodemask > > 2. return NUMA_NO_NODE > > I think I would lean towards the first. > > I guess we'd need a way for your new helper to deal with both cases > (is_fault vs. !is_fault), and make a decision based on that. > > > For your use case, you can then decide what would be appropriate. It's a > good question what the appropriate action would be: 1) sounds better, > but I do wonder if we would rather want to distribute the folios in a > different way across applicable nodes, not sure ... Yes, I was thinking about that too, but I felt that adding state somewhere or using randomness to distribute the folios was incorrect, especially since those policies are not the focus of this patchset. I think I'll move forward with option 1 for now. Thanks, Bijan