On Fri, Dec 13, 2024 at 11:45 AM 'Liam R. Howlett' via kernel-team
[off-list ref] wrote:

* Lorenzo Stoakes [off-list ref] [241213 10:16]:

quoted

On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote:

quoted

On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes
[off-list ref] wrote:

...

quoted

quoted

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.

I build-tested most of these except (csky and loongarch) and ran
android runtime (ART) tests on arm64 and x86. I can try to spin up a
few of the others and will add it to the description.

quoted

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.

Initially I think we can remove the mmap hint portion of the logic;
and follow up with removing arch_get_unmapped_area[_topdown](). Some
of those may not make sense to consolidate e.g. powerpc's
slice_get_unmapped_area() which doesn't share much in common with the
rest.

Thanks,
Kalesh

Thanks,
Liam

To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.