From: Shivank Garg <shivankg@amd.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: x86@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org,
jack@suse.cz, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-api@vger.kernel.org,
linux-arch@vger.kernel.org, kvm@vger.kernel.org,
chao.gao@intel.com, pgonda@google.com, thomas.lendacky@amd.com,
seanjc@google.com, luto@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
arnd@arndb.de, pbonzini@redhat.com, kees@kernel.org,
bharata@amd.com, nikunj@amd.com, michael.day@amd.com,
Neeraj.Upadhyay@amd.com, linux-coco@lists.linux.dev
Subject: Re: [RFC PATCH 0/4] Add fbind() and NUMA mempolicy support for KVM guest_memfd
Date: Fri, 8 Nov 2024 14:51:12 +0530 [thread overview]
Message-ID: <d9dc54e8-080f-4dc3-b13e-b65248c25a56@amd.com> (raw)
In-Reply-To: <ZyzYUOX_r3uWin5f@casper.infradead.org>
On 11/7/2024 8:40 PM, Matthew Wilcox wrote:
> On Thu, Nov 07, 2024 at 02:24:20PM +0530, Shivank Garg wrote:
>> The folio allocation path from guest_memfd typically looks like this...
>>
>> kvm_gmem_get_folio
>> filemap_grab_folio
>> __filemap_get_folio
>> filemap_alloc_folio
>> __folio_alloc_node_noprof
>> -> goes to the buddy allocator
>>
>> Hence, I am trying to have a version of filemap_alloc_folio() that takes an mpol.
>
> It only takes that path if cpuset_do_page_mem_spread() is true. Is the
> real problem that you're trying to solve that cpusets are being used
> incorrectly?
>
> Backing up, it seems like you want to make a change to the page cache,
> you've had a long discussion with people who aren't the page cache
> maintainer, and you all understand the pros and cons of everything,
> and here you are dumping a solution on me without talking to me, even
> though I was at Plumbers, you didn't find me to tell me I needed to go
> to your talk.
>
> So you haven't explained a damned thing to me, and I'm annoyed at you.
> Do better. Starting with your cover letter.
Hi Matthew,
I apologize for any misunderstanding and not providing adequate context.
To clarify:
- You may recall this work from its earlier iteration as an
IOCTL-based approach, where you provided valuable review comments [1].
- I was not physically present at LPC. The discussion happened through
the mailing list [2] and lobby discussion with my colleagues who visited
Vienna.
- Based on feedback, particularly regarding the suggestion to consider
fbind() as a more generic solution, we shifted to the current approach.
I posted this as *RFC* specifically to gather feedback on the feasibility of
this approach and to ensure I'm heading in the right direction.
Would you be willing to help me understand:
1. What additional information would be helpful to you and other reviewers?
2. How cpusets can be used correctly to fix this? (your point on
cpuset_do_page_mem_spread() is interesting and I'll investigate it more
thoroughly to understand).
I'll work on improving the cover letter to better explain the problem space
and proposed solution.
Thank you for the valuable feedback.
[1] https://lore.kernel.org/linux-mm/ZuimLtrpv1dXczf5@casper.infradead.org
[2] https://lore.kernel.org/linux-mm/ZvEga7srKhympQBt@intel.com
Best regards,
Shivank
next prev parent reply other threads:[~2024-11-08 9:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-05 16:45 [RFC PATCH 0/4] Add fbind() and NUMA mempolicy support for KVM guest_memfd Shivank Garg
2024-11-05 16:45 ` [RFC PATCH 1/4] mm: Add mempolicy support to the filemap layer Shivank Garg
2024-11-05 16:55 ` [RFC PATCH 2/4] Introduce fbind syscall Shivank Garg
2024-11-05 16:55 ` [RFC PATCH 3/4] KVM: guest_memfd: Pass file pointer instead of inode in guest_memfd APIs Shivank Garg
2024-11-05 16:55 ` [RFC PATCH 4/4] KVM: guest_memfd: Enforce NUMA mempolicy if available Shivank Garg
2024-11-05 18:55 ` [RFC PATCH 0/4] Add fbind() and NUMA mempolicy support for KVM guest_memfd Matthew Wilcox
2024-11-07 8:54 ` Shivank Garg
2024-11-07 15:10 ` Matthew Wilcox
2024-11-08 9:21 ` Shivank Garg [this message]
2024-11-08 17:31 ` Paolo Bonzini
2024-11-11 11:02 ` Vlastimil Babka
2024-11-11 22:14 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9dc54e8-080f-4dc3-b13e-b65248c25a56@amd.com \
--to=shivankg@amd.com \
--cc=Neeraj.Upadhyay@amd.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bharata@amd.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jack@suse.cz \
--cc=kees@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=michael.day@amd.com \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).