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 A497FC71136 for ; Mon, 16 Jun 2025 17:43:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 273706B0089; Mon, 16 Jun 2025 13:43:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 224876B008A; Mon, 16 Jun 2025 13:43:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13AAF6B0092; Mon, 16 Jun 2025 13:43:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0228B6B0089 for ; Mon, 16 Jun 2025 13:43:28 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AAD211D6CB7 for ; Mon, 16 Jun 2025 17:43:27 +0000 (UTC) X-FDA: 83561985654.20.ADA4C7B Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) by imf11.hostedemail.com (Postfix) with ESMTP id 8C27B4000F for ; Mon, 16 Jun 2025 17:43:25 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=siap14hB; spf=pass (imf11.hostedemail.com: domain of gourry@gourry.net designates 209.85.222.178 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750095805; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5/4yKvTkyWVd/1WyBWdEpHbqHXZjmiKnTF2OwJ8AWbI=; b=Qsv/z++9RHd+G6WFiKc1TgwM34jgjq0ChpelGjq78pvJPKbusGvCpXPDZ3j1LdJ65/+xnG LZH1C/mEyBfX5BVCCAWSBYF5yA1EA3vYPcpbwxnESgy3bbDGuQgG/qN7pmAInU4jSQo2Dp fobdfUcXAbNgXlUHJt0hxJ+jZ86Xln8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=siap14hB; spf=pass (imf11.hostedemail.com: domain of gourry@gourry.net designates 209.85.222.178 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750095805; a=rsa-sha256; cv=none; b=1CzwVzxzzEoFoNNpxFfmKw2A3ZIUQ1xBiJIQsuqG8+kzNshaiJZ+T2g2EpKR1VF0S8L+Ji L34YRAmuEjVdrsd5LLVGwjVbjb9h0BdtT4oEKHDzBWe0Z1V55ZuX8dk74kh8A/Ie5L84Ss mPcgYyi9Rit3JPPHzTuZOuTvCZLhhxk= Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-7d20f799fe9so562860585a.2 for ; Mon, 16 Jun 2025 10:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1750095804; x=1750700604; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5/4yKvTkyWVd/1WyBWdEpHbqHXZjmiKnTF2OwJ8AWbI=; b=siap14hBc2aShaZmh4GxR8P9qnARnEtJteHfgJj2J/fn3cmjhvEP3dFzV41mu8smNV 7bwzymp6J2eTVcqAt2tBjd1d2P6nIJtAbVXXXl+2FnMu4LxSroOX5I2hMUBejk0QF3xw PKll/u9hEYJrUc3r4+KLVckgq8afhveFd0JFZWgEh3OJcl+5uMIEsqXWTzF80xCpHw53 hQHiaeJ2GYfWvwjiii80uzIVJLCTjO2iIPUfEJgFLpjtcC6ZAg5EpbIpS9UCcJLYdxYe RxOpQKkQfULFYMWGwN2yZ+Zl/OHdw2W58jHLlNttZe/Cry8khjGhi20vP09mwyZH96Jj jGKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750095804; x=1750700604; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5/4yKvTkyWVd/1WyBWdEpHbqHXZjmiKnTF2OwJ8AWbI=; b=hCVDwgISiRjjjIAzQk6HQQVxe2NcU2buDGx7Ui1NhWYWbS9bJghoyiisVP9pSQhhiG 3gp7/0KHZJkurYWuxM7DRoINGSCScE/b+DK3WoOhEhysr6ksAM6WZH9PU2+JU7l3Jy+K muphlTn4jhEVt+i8Dxy9eaGaVx43ghbglUdN3nQNXE5wJrQocC1JcebfaG9M1vgW6xp4 uSa4VKiHc3mnE4B0hoZjiNsulZLp+cWvD1g5ne/rhZyAhIs6YbOeuHbzoh+LtdFs3l/G ah9PUgNGmL59R9VGthLtfWe+Ug8ha3V4e3uEk3AR5CX8pijkH1ri1tJeGDAJ342P62R2 qMKw== X-Forwarded-Encrypted: i=1; AJvYcCXdl/nFIsMqN88VxUwWLjE6vVtlNA0kQCNKxjdWI6hE7HNNmdR4VUB5yjmnlDs6pwifBKipkZ1wWw==@kvack.org X-Gm-Message-State: AOJu0YyW/L25/TLcIs8GZ6goOwRjK32yk4kZaVGYGXNWY7LdQz1JxhmN lexvra/T9nLhg4poWWKkkRMroMjb8M7ax+EP1jehtDMznouPblxoEszv+AG5G99gp3M= X-Gm-Gg: ASbGncvKVdFl6z4DPwDLTpfmh9pZiwSXQgyHxzVaqVV7BN86e5pJB9dGEhnk/IqR/xw En6jsNWeuWELT3AHcxSs0QVcTmtnth3xUZ8QvCFjsZbj03D+5bVOmzLGffSYgiIZw39htIBrx3I yfCJRRa/9xH9hVrsD/C40VoNY4DHTL9pBrAuLcKTruuii8sIKAs9YPYQaLVYX07MVpIvSB0SRNF BZZZ3ggcLh8EzOc0afRNry+tdgDWR6hr7jx3obzoyk52nd5MOAN8ZjX6sItzuWvTBmaXggI3soQ Qv8SzP1M0PK5NtfbXcFGYq1wx8j2gwJEGgl2iThJ28Pw8t810m/ImEdYXg== X-Google-Smtp-Source: AGHT+IHUYY/n0yispU7eDUw6kgUep9wTEjSSBo8Jf7TL4kZ2IW3kTqXn60pb1DKcSyyGtFKJ/3beCA== X-Received: by 2002:a05:620a:3728:b0:7d3:8c44:b7b1 with SMTP id af79cd13be357-7d3c6c0962emr1601991885a.3.1750095804599; Mon, 16 Jun 2025 10:43:24 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F ([2620:10d:c091:400::5:cf64]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4a72a0fcd34sm51514371cf.0.2025.06.16.10.43.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Jun 2025 10:43:23 -0700 (PDT) Date: Mon, 16 Jun 2025 12:43:21 -0500 From: Gregory Price To: Bijan Tabatabai Cc: David Hildenbrand , 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, 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 Subject: Re: [RFC PATCH 1/4] mm/mempolicy: Expose policy_nodemask() in include/linux/mempolicy.h Message-ID: References: <20250612181330.31236-1-bijan311@gmail.com> <20250612181330.31236-2-bijan311@gmail.com> <5a50eeba-b26d-4913-8016-45278608a1ee@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: p5krn6c8upsdf34iifxcop7tm5ou8yxe X-Rspamd-Queue-Id: 8C27B4000F X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1750095805-88340 X-HE-Meta: U2FsdGVkX1+BxAxeARg2vdGHiVPCGUa6D5ive9WPQIK5pBoz2XyGRkWnjo/KWKaC+63fq+d+KCJFBtIw599fgXnwd9FLO9znDtYlRTDeGyMhPrjswYOKgbLUFPFM0Lmmkhe1Q0E2n+dlisN++gZneCDE4NX1xJIOp3S/jeifDXzIZpUS2NZy2SDCkLyJmMQesIi0gkUCJvDndO3viG4NctzvB+LQQGbttM5nu4o2kExCGnSExUsOGjQnwX+sHR6LUyOvl89+1NYp0qB0yhEWTkep24982hRp17Zf+qndd33nrXYmVJhDT6xoMlKdhIDTArxe8tfHQpcjYvF5gYSYt/Okt7B30KjO92OI+JRzaEtwfGjBMyjwz3w3xqj4udKrNaSc6U2rVm7/cvRphvq6SUGOTYOuMbZi31Is7KlY6rPyE7BaYwYTVLnwvUI/1T26ksydr+VOb8f5AFVQdDVTSQ372sSHvmVcT7zzsehyxu3PaJWs8AlDXxdRDAWzuibKDCxvcsfBNy9ZPztA6twUvXWE4WvZ/+HYYWErBAkMV4Bu8kOeENF8KrvoQ+xs72PI3ruAEHMvTqTQsnXzgcIQpDnIFT3sOM2rFQlftnCu6lBaqQ2oDnGEUqNcsTAIUww1BjJP0YSvtpE+FaQKFY9VEaw8m+PTI8mIyYTohjb7U10YaePjkhgRMlGkrIxGGrMh+AZ3c0YPDtRGJILjkbtHE1n90CB2zw4iFurWaELSPPL1Y03mA108QEZuF8KejdAJuVBsd6wVnZ+R45VVhkyWXFQDHMUDUyb6cabh/TLIJrt5L+qq1oWfdZlbF6ZDbGDZEjL3AY3B0t0Rx/pN4C66OpVDr23ZX5Yo7NMzLXoekryXrv3jmWsiNef5ZqtnMMhSkfsmy1SmunkJdy0cOzcSqhCRVyTL2zPrwfyNSUZKgOg7aY/s11GAV4bjyu4lziFbmX6nBl7RgNr6C6xl7SJ AH/Jd9Gw 07idJ+LrBq6/D8kRJi7pERLTHXUV5MPq1SiQpy84PnhqWlCwt/CZ3PSosDxTAxK57UTKiPrkSqr80kfzbDtOjiNRZKf5guFTemDMVurry5ak3Z7Ke7/4eCkvhFHaSSPrktWXVgQLU2wXj6/PDIKvXWs6D68PAk7fd8fnrWALYwHHdHNlO/VRaU9l6PbWmvCVM2b247x15rgsug/gVa29enU2n3EPAZpNI+W0anh5wzB6luobXnqcYI11RkvSU3+XAR+Rxw1Wp5Ao8xauwcseutgGAevftxbZfDSde4Iyz5yDXjres4ravpcGF5JA39fTRtFV2uWRfbx8dWPT/3aledM2ZEKiTkPjaYeCgu+7IfXLRpvth7BmYxE/MS8znX5604DghVJgLbWk3qCN1rVHFKNUCwo4CEid41j3e5xIIw0CC5BMyxMgx7Gef4pUXQbn1UDDhzgs0nXga8AGun2iq5xtfAAn2eDg6fW+Rs4wnn/0APu0= 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 09:16:55AM -0500, Bijan Tabatabai wrote: > > > > 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. > Hate to interject here, but this gets worse the further you dig in. The mempolicy interface as a whole has many, many, many hidden references to current->mempolicy and current->mems_allowed. External interface references to a task or vma mempolicy is a problem i explored somewhat extensively when I prototyped `set_mempolicy2()`. It did not go well. Generally, mempolicy is not well structured to allow external actors on a task's mempolicy. Accessing a task's mempolicy requires operating in a task's context or at least taking a reference on that task's mempolicy (which requires taking the task_struct lock). I will just say that mempolicy is *extremely* current-task centric - and very much allocation-time centric (i.e. the internal workings don't really want to consider migration all that much). You'll probably find that this project requires rethinking mempolicy's external interfaces in general (which is sorely needed anyway). I think this path to modifying mempolicy to support DAMON is a bit ambitious for where mempolicy is at the moment. You may be better off duplicating the interleave-weight logic and making some helper functions to get the weight data, and then coming back around to generalize it later. ~Gregory