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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> [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@xxxxxxxxxx> 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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux