On Fri, Dec 13, 2024 at 11:45 AM 'Liam R. Howlett' via kernel-team <kernel-team@xxxxxxxxxxx> wrote: > > * 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. > 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. > > > > 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@xxxxxxxxxxx. >
