From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Kalesh Singh <kaleshsingh@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
vbabka@suse.cz, yang@os.amperecomputing.com, riel@surriel.com,
david@redhat.com, minchan@kernel.org, jyescas@google.com,
linux@armlinux.org.uk, tsbogend@alpha.franken.de,
James.Bottomley@hansenpartnership.com,
ysato@users.sourceforge.jp, dalias@libc.org,
glaubitz@physik.fu-berlin.de, davem@davemloft.net,
andreas@gaisler.com, tglx@linutronix.de, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, chris@zankel.net,
jcmvbkbc@gmail.com, bhelgaas@google.com, jason.andryuk@amd.com,
leitao@debian.org, linux-alpha@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
loongarch@lists.linux.dev, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-mm@kvack.org,
kernel-team@android.com, android-mm@google.com,
Jann Horn <jannh@google.com>
Subject: Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint()
Date: Fri, 13 Dec 2024 11:45:32 -0500 [thread overview]
Message-ID: <x2y7rewvmri25wj72qaeuunqqsqj7pqcliahoxkprcbfxg5owv@icvnojkhrdch> (raw)
In-Reply-To: <9675c409-b495-46a5-a90c-c952892b4121@lucifer.local>
* Lorenzo Stoakes <lorenzo.stoakes@oracle.com> [241213 10:16]:
> On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote:
> > On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes
> > <lorenzo.stoakes@oracle.com> wrote:
...
> >
> > On the technical side, Liam is right that the copy-pasted arch code
> > has inconsistencies (missing checks, order of checks, ...). I agree
> > there’s room for further consolidation. I’ll take another stab at it
> > and resend it as an RFC with an updated cover letter, as Lorenzo and
> > others suggested.
Thanks. Can you please include what platforms you have tested in your
cover letter (and level of testing - booting, running something, etc).
If you have not tested them, then it might be worth it to have it as an
RFC to point this out - at least initially. Some of these are very
difficult to set up for testing, but it is also possible that you did
that and the maintainers/people who usually test these things will
assume it's fine if you don't spell out what's going on.
>
> The most useful thing here as well to help us understand would be to write
> more in the cover letter to expand on what it is you ultimately what to
> achieve here - it seems like an extension on the existing THP work on a
> per-arch basis (I may be wrong)? So adding more detail would be super
> useful here! :)
>
> We do hope to avoid arch hooks if at all possible explicitly for the reason
> that they can be applied at unfortunate times in terms of locking/whether
> the objects in question are fully/partially instantiated, VMA visibility
> etc. etc. based on having had issues in these areas before.
>
> Also if a hook means 'anything' can happen at a certain point, it means we
> can't make any assumptions about what has/hasn't and have to account for
> anything which seriously complicates things.
>
> Ideally we'd find a means to achieve the same thing while also exposing us
> as little as possible to what may be mutated.
Yes, I'm not sure of what your plans are, but I would like to see all of
these custom functions removed, if at all possible.
Thanks,
Liam
next prev parent reply other threads:[~2024-12-13 16:46 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 23:27 Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 01/16] mm: Introduce generic_mmap_hint() Kalesh Singh
2024-12-12 20:08 ` Yang Shi
2024-12-11 23:27 ` [PATCH mm-unstable v2 02/16] mm: x86: Introduce arch_mmap_hint() Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 03/16] mm: arm: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 04/16] mm: alpha: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 05/16] mm: arc: Use generic_mmap_hint() Kalesh Singh
2024-12-12 21:13 ` Liam R. Howlett
2024-12-11 23:27 ` [PATCH mm-unstable v2 06/16] mm: csky: Introduce arch_mmap_hint() Kalesh Singh
2024-12-12 21:40 ` Liam R. Howlett
2024-12-13 1:39 ` Andrew Morton
2024-12-11 23:27 ` [PATCH mm-unstable v2 07/16] mm: loongarch: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 08/16] mm: mips: Introduce arch_align_mmap_hint() Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 09/16] mm: parisc: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 10/16] mm: s390: Use generic_mmap_hint() Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 11/16] mm: sh: Introduce arch_mmap_hint() Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 12/16] mm: sparc32: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 13/16] mm: sparc64: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 14/16] mm: xtensa: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 15/16] mm: powerpc: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 16/16] mm: Respect mmap hint before THP alignment if allocation is possible Kalesh Singh
2024-12-12 20:11 ` Yang Shi
2024-12-12 21:02 ` [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint() Liam R. Howlett
2024-12-12 22:51 ` Lorenzo Stoakes
2024-12-13 1:36 ` Andrew Morton
2024-12-13 8:59 ` Lorenzo Stoakes
2024-12-13 15:06 ` Kalesh Singh
2024-12-13 15:16 ` Lorenzo Stoakes
2024-12-13 16:45 ` Liam R. Howlett [this message]
2024-12-13 17:08 ` Kalesh Singh
2024-12-12 22:01 ` Matthew Wilcox
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=x2y7rewvmri25wj72qaeuunqqsqj7pqcliahoxkprcbfxg5owv@icvnojkhrdch \
--to=liam.howlett@oracle.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=android-mm@google.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=chris@zankel.net \
--cc=dalias@libc.org \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=jannh@google.com \
--cc=jason.andryuk@amd.com \
--cc=jcmvbkbc@gmail.com \
--cc=jyescas@google.com \
--cc=kaleshsingh@google.com \
--cc=kernel-team@android.com \
--cc=leitao@debian.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=lorenzo.stoakes@oracle.com \
--cc=minchan@kernel.org \
--cc=riel@surriel.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
--cc=yang@os.amperecomputing.com \
--cc=ysato@users.sourceforge.jp \
/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