Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint()

"Liam R. Howlett" <[email protected]>
Newsgroups gmane.linux.ports.ppc64.devel,gmane.linux.ports.alpha,gmane.linux.kernel,gmane.linux.kernel.arc,gmane.linux.ports.arm.kernel,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc,gmane.linux.kernel.mm
Message-ID <x2y7rewvmri25wj72qaeuunqqsqj7pqcliahoxkprcbfxg5owv@icvnojkhrdch>
* Lorenzo Stoakes <[email protected]> [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
> > <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.