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 16DD3C282C6 for ; Fri, 28 Feb 2025 17:51:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A3516280003; Fri, 28 Feb 2025 12:51:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E5BF280001; Fri, 28 Feb 2025 12:51:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AD6C280003; Fri, 28 Feb 2025 12:51:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4EF59280001 for ; Fri, 28 Feb 2025 12:51:06 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5ECEE1C8F9F for ; Fri, 28 Feb 2025 17:51:05 +0000 (UTC) X-FDA: 83170094490.13.6A020F3 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) by imf17.hostedemail.com (Postfix) with ESMTP id 2977F40010 for ; Fri, 28 Feb 2025 17:51:02 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PF8ku9Pj; spf=pass (imf17.hostedemail.com: domain of 3hffBZwsKCMAgiqkxrk4ztmmuumrk.iusrot03-ssq1giq.uxm@flex--ackerleytng.bounces.google.com designates 209.85.216.74 as permitted sender) smtp.mailfrom=3hffBZwsKCMAgiqkxrk4ztmmuumrk.iusrot03-ssq1giq.uxm@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740765063; 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:dkim-signature; bh=6NyvctiqOUa3n9gcjc6FONh/SC/E+DJ6Q+NnNJwCpW4=; b=uWVPJWyk0KFaH43GqgX+9Mc0BJi3VlIXZj58YliHHIoABEH+3+dF/yiC9oEhlPlPLqkh2Y IdGa4NMaqrIIobVMswnaZTzpiE4aNJwyHrxYZN/VbPhng9iubBhcHStpuvNOWy0e3hFQtR GDmv10/wI+L653t7jMR4AO+vhvMnSEQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740765063; a=rsa-sha256; cv=none; b=3nhszeCvcvgpftjg9EMD1z9ajVvM6Cyfkz7zBsESrrcDno+gRMF/hZ6b/h7k0SmhKgaywu WkkUsJmVBXTjmjDzGq8TBz9tHGaHzh+yi5W+tfcPhq+NroGLSEN6vCUhTUgoBq+sXAPMpw wIqjDfZvJeqLGzZ+zMbTXMk7S8zdjWA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PF8ku9Pj; spf=pass (imf17.hostedemail.com: domain of 3hffBZwsKCMAgiqkxrk4ztmmuumrk.iusrot03-ssq1giq.uxm@flex--ackerleytng.bounces.google.com designates 209.85.216.74 as permitted sender) smtp.mailfrom=3hffBZwsKCMAgiqkxrk4ztmmuumrk.iusrot03-ssq1giq.uxm@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2f816a85facso4973521a91.3 for ; Fri, 28 Feb 2025 09:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740765062; x=1741369862; darn=kvack.org; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=6NyvctiqOUa3n9gcjc6FONh/SC/E+DJ6Q+NnNJwCpW4=; b=PF8ku9PjQZYsjIOQyLgy1YQNHLvoOh5L2CqOBrlM6XW/RuihwAINlehJ2bsQhKQzBO dcE3guSlNtAk/VKBC0BsgPmiwzzkSh24/Ng1OeW1MqEmoqGfLsJDO/47KKIewTHqFlhj oUFtSo5W0YTcqXAhY3O3QVUjveUdYjvGVM+qSBMwtPQBaXrbpUtGqZBhX2pmVIeSTgxE OIbkV0ka8Z6V8VrThvd3GiHGDep4xSsb3OqTea724nS9PXlQOoHBf6ury+R12S32UChx F3ViwrfLzAFMwVum0/yGPpzYtko+6oKE7EpFz2cD/oCeVykfBSAW5mHdsknxIwUps2pu Acrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740765062; x=1741369862; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6NyvctiqOUa3n9gcjc6FONh/SC/E+DJ6Q+NnNJwCpW4=; b=gwzjJIoNrXJYv7zugDyqOIh8UpAlNavPD/yjMMaQLDQtCmlBsq9ZlxWcMi9O+gMFw4 JgD9lJcie6F91092k6hRXHwuRGsNGvq2YV13tnlkZOdXnyC1SkZIERmQoAT0WHxrkxzi ETHxckysOVbzfYeXMkiWzjfJjIpRc+25J5EvZXNKEtPQk6Mz1ei5/azqkoezYDKpiDdo y8mkRubVv6lviKfZT3Bpe0tA3JFv/uDM+OGoysONY0wnGITNJwsiWDMXmq+imcfXh5yP 89WLC9IXbiTv0eM7ZxAaNnkP23hJvxytAKCZtqIV7jX3q3uTW88uAQhhic5qlrLtYE1+ RAgw== X-Forwarded-Encrypted: i=1; AJvYcCWYzrNe/itSWQvxrxXEjsUoXYqClUCkIzso3he/EHd6avB8RxM5oKrNemDBylVDb6j7N9aYRBjcnA==@kvack.org X-Gm-Message-State: AOJu0YyGXgVv7EgTvP84eSepi/0d7WogTf6xDFNnssOq8Zzc3hpvxAKL 2/y91Khtme/xmezVedf8Dh6yIdCgf0JT5tXjl1yZpLpoBjTDMVCINR3B3Y9oPdQq4fx/FQqXcTi GSYtAY7drs+V2h6neRAf1bQ== X-Google-Smtp-Source: AGHT+IFcKOkFii9o7crCwA/34cEMAOGG0lMrGvepv/XtLz3NB8cMI+uVglV3v5h1Vekl5o+ofsDoALDBoCUPhMpdGg== X-Received: from pjbrr3.prod.google.com ([2002:a17:90b:2b43:b0:2fc:1eb0:5743]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4990:b0:2ee:f80c:687c with SMTP id 98e67ed59e1d1-2febac07e18mr6481041a91.31.1740765061874; Fri, 28 Feb 2025 09:51:01 -0800 (PST) Date: Fri, 28 Feb 2025 17:51:00 +0000 In-Reply-To: <503c4ba7-c667-444a-b396-e85c46469f0a@suse.cz> (message from Vlastimil Babka on Fri, 28 Feb 2025 15:17:11 +0100) Mime-Version: 1.0 Message-ID: Subject: Re: [PATCH v6 1/5] mm/filemap: add mempolicy support to the filemap layer From: Ackerley Tng To: Vlastimil Babka Cc: shivankg@amd.com, akpm@linux-foundation.org, willy@infradead.org, pbonzini@redhat.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, chao.gao@intel.com, seanjc@google.com, david@redhat.com, bharata@amd.com, nikunj@amd.com, michael.day@amd.com, Neeraj.Upadhyay@amd.com, thomas.lendacky@amd.com, michael.roth@amd.com, tabba@google.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 5dmxufrghf9cqsahamgz3aausfon94cj X-Rspamd-Queue-Id: 2977F40010 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740765062-593612 X-HE-Meta: U2FsdGVkX1/BY6bv6ZvwIq8lwqtD1jQuQ2vvsj7lD7UgODl5UKW5L+s4ynwRSwyQJjytKSMLb9DfyuUbrC8bQsm8likNTWzpV14b6RxUQjxeoC3jAK0jQSnrzeYIX4+KshwA3lP5+3+TwZ0lGttARslp6iPk2cIFVCf8hAMpKkL9Hlk+t9yY9D0ltZwg3gfbPW/TZ/wfF8Ugnl6nZFcLwLZCwrUotkS/fDTkh6Orb/Crcn0SPe67Z0/SCzCOtX6xOkvAW8J8b0LC1O2Tom+8N9VYLEkjTS/FM4Gce+6EzVfnlbaqW6vSq1e1q/x/FQIWeyjZzzeUKLcDF3e/FG6c/jaK0MG38pJZwxTse+ZE/W9BjdONfjJiKUY2ADBNVX0Q3nxQU1HChLEdDSrmqiPS8zttL/Monu/BtaXJbTomIaAubSw6NwZsU2oysfiEQz2EwQDXsNza1TwXVrhrj6aXo/44DtTtIisxRBJpZrTQlXNpSICgkYhQm8W4fDwu0XELMIevYkmfdi3BOZ3Mn0iaoSKN6VFZugJbXgd3DNcRauLuVieEnT0tyFv8HJSmiOcdpbar4qMdi/X1FdSfL4twuD4astIQsfflb2WciU6+9nV7DTmBMMKSJ/9LPXODMz6fRzzQK+2utincDtt0j2rcaY/AMd4mXxXPGfuuPJ8/f8+9sBJ5AzY+J5BVTUD1hs4OdoIFYkPLOkanbrzpbR9KlmtldXl7orUT4egV4rH2TLjz5W2iP14jKx5ho8Q71oHBAvii0l7HseVZXZLEgbce8q979QhpVXbRgwNeKMP3TSxKv6SDpuwPo6Qf2XPa/j+UE83ZSmcHVuVtWUm8rmkxAfwcEf39M96bGZ2OOYUbnc0iOqSId3o/BfRCqS/RQCTyhiufAGR3mS6lUb2U3razPeMOsQj6Z+oXGR58tyPGSyWfDxmE0wKSzmfmQfC5BB5Rbd5nyI7sAx5eUEbAkjL uH01ji7x w8wr1hX85Zrf0m0c/nTgoS4rK7mbwHSH5X7MZALMltbvg2OgT97shdBQMjPyOrGYRy1CqDX6qUcdp1KQjvYOBeECbA56D6UVVKOGCjKzyImYKegyFUhPkmtDDyedC4HwjzCba3WAdAkF8kbNqQDC4MB8tJRFYaOuS+vGEk3UlEnGBBQQu0GLnoPyDoBfkPqrzOs0eTjAUdVqZ8WObKEeT8cOhqIR05uf+UBthyQUi0sHMFxDpKxRjkQJMTUYAb0jmiRT20Y9spDhnqXPYLDbNEt6PprlnG1u0TL/LaZVlbsMtHmQYnHiLS8b7iyYG2FLYXgXuD4KvAqFgtYz1gT0mlO4gVJn8wqgdXALb+hyoacPdKyQrzdRpNrueT6fsAClnTyOjtqv9PtMnU9ZjzPcwJ68VeX2GZsb54pgb3yMawAJ5X6cpX3v2Nb6mX7HGDUECKwKfsGoD9s0EIr1/i6t68h3aa7S9Bs+XYzeaJRpYQuTflqcwo7q6YAUs2uTl4cXgedREZsrEikoA5ixHenQbzFxnA2FaGXtA5GMkwy4ngv7n4uSN99vq/lRNEzBsgikoabxn 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: Vlastimil Babka writes: > On 2/26/25 09:25, Shivank Garg wrote: >> From: Shivansh Dhiman >> >> Add NUMA mempolicy support to the filemap allocation path by introducing >> new APIs that take a mempolicy argument: >> - filemap_grab_folio_mpol() >> - filemap_alloc_folio_mpol() >> - __filemap_get_folio_mpol() >> >> These APIs allow callers to specify a NUMA policy during page cache >> allocations, enabling fine-grained control over memory placement. This is >> particularly needed by KVM when using guest-memfd memory backends, where >> the guest memory needs to be allocated according to the NUMA policy >> specified by VMM. >> >> The existing non-mempolicy APIs remain unchanged and continue to use the >> default allocation behavior. >> >> Signed-off-by: Shivansh Dhiman >> Signed-off-by: Shivank Garg > > > >> --- a/mm/filemap.c >> +++ b/mm/filemap.c >> @@ -1001,11 +1001,17 @@ int filemap_add_folio(struct address_space *mapping, struct folio *folio, >> EXPORT_SYMBOL_GPL(filemap_add_folio); >> >> #ifdef CONFIG_NUMA >> -struct folio *filemap_alloc_folio_noprof(gfp_t gfp, unsigned int order) >> +struct folio *filemap_alloc_folio_mpol_noprof(gfp_t gfp, unsigned int order, >> + struct mempolicy *mpol) >> { >> int n; >> struct folio *folio; >> >> + if (mpol) >> + return folio_alloc_mpol_noprof(gfp, order, mpol, >> + NO_INTERLEAVE_INDEX, Could we pass in the interleave index instead of hard-coding it? >> + numa_node_id()); >> + >> if (cpuset_do_page_mem_spread()) { >> unsigned int cpuset_mems_cookie; >> do { >> @@ -1018,6 +1024,12 @@ struct folio *filemap_alloc_folio_noprof(gfp_t gfp, unsigned int order) >> } >> return folio_alloc_noprof(gfp, order); >> } >> +EXPORT_SYMBOL(filemap_alloc_folio_mpol_noprof); >> + >> +struct folio *filemap_alloc_folio_noprof(gfp_t gfp, unsigned int order) >> +{ >> + return filemap_alloc_folio_mpol_noprof(gfp, order, NULL); >> +} >> EXPORT_SYMBOL(filemap_alloc_folio_noprof); >> #endif > > Here it seems to me: > > - filemap_alloc_folio_noprof() could stay unchanged > - filemap_alloc_folio_mpol_noprof() would > - call folio_alloc_mpol_noprof() if (mpol) > - call filemap_alloc_folio_noprof() otherwise > > The code would be a bit more clearly structured that way? > I feel that the original proposal makes it clearer that for all filemap folio allocations, if mpol is defined, anything to do with cpuset's page spread is overridden. Just a slight preference though. I do also agree that having filemap_alloc_folio_mpol_noprof() call filemap_alloc_folio_noprof() would result in fewer changes. >> @@ -1881,11 +1893,12 @@ void *filemap_get_entry(struct address_space *mapping, pgoff_t index) >> } >> >> /** >> - * __filemap_get_folio - Find and get a reference to a folio. >> + * __filemap_get_folio_mpol - Find and get a reference to a folio. >> * @mapping: The address_space to search. >> * @index: The page index. >> * @fgp_flags: %FGP flags modify how the folio is returned. >> * @gfp: Memory allocation flags to use if %FGP_CREAT is specified. >> + * @mpol: The mempolicy to apply when allocating a new folio. >> * >> * Looks up the page cache entry at @mapping & @index. >> * >> @@ -1896,8 +1909,8 @@ void *filemap_get_entry(struct address_space *mapping, pgoff_t index) >> * >> * Return: The found folio or an ERR_PTR() otherwise. >> */ >> -struct folio *__filemap_get_folio(struct address_space *mapping, pgoff_t index, >> - fgf_t fgp_flags, gfp_t gfp) >> +struct folio *__filemap_get_folio_mpol(struct address_space *mapping, pgoff_t index, >> + fgf_t fgp_flags, gfp_t gfp, struct mempolicy *mpol) >> { >> struct folio *folio; >> >> @@ -1967,7 +1980,7 @@ struct folio *__filemap_get_folio(struct address_space *mapping, pgoff_t index, >> err = -ENOMEM; >> if (order > min_order) >> alloc_gfp |= __GFP_NORETRY | __GFP_NOWARN; >> - folio = filemap_alloc_folio(alloc_gfp, order); >> + folio = filemap_alloc_folio_mpol(alloc_gfp, order, mpol); >> if (!folio) >> continue; >> >> @@ -2003,6 +2016,13 @@ struct folio *__filemap_get_folio(struct address_space *mapping, pgoff_t index, >> folio_clear_dropbehind(folio); >> return folio; >> } >> +EXPORT_SYMBOL(__filemap_get_folio_mpol); >> + >> +struct folio *__filemap_get_folio(struct address_space *mapping, pgoff_t index, >> + fgf_t fgp_flags, gfp_t gfp) >> +{ >> + return __filemap_get_folio_mpol(mapping, index, fgp_flags, gfp, NULL); >> +} >> EXPORT_SYMBOL(__filemap_get_folio); >> >> static inline struct folio *find_get_entry(struct xa_state *xas, pgoff_t max,