On Thu, Oct 24, 2024 at 09:45:37AM +0200, David Hildenbrand wrote: > On 24.10.24 09:34, Lorenzo Stoakes wrote: > > On Wed, Oct 23, 2024 at 04:04:05PM -0700, Andrew Morton wrote: > > > On Wed, 23 Oct 2024 17:24:38 +0100 Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote: > > > > > > > > > > > ... > > > > > > > > Existing mechanism for performing a walk which also installs page table > > > > entries if necessary are heavily duplicated throughout the kernel, > > > > > > How complicated is it to migrate those to use this? > > > > I would say probably somewhat difficult as very often people are doing quite > > custom things, but I will take a look at seeing if we can't make things a little > > more generic. > > > > I am also mildly motivated to look at trying to find a generic way to do > > replaces... > > > > Both on the TODO! > > I'm not super happy about extending the rusty old pagewalk API, because it's > inefficient (indirect calls) and not future proof (batching, large folios). Yeah it could be improved, but I think the ideal way would be to genericise as much as we can and 'upgrade' this logic. > > But I see how we ended up with this patch, and it will be easy to convert to > something better once we have it. Yes, I was quite happy with what an ultimately small delta this all ended up being vs. the various other alternatives (change zap logic, introduce custom page fault mechanism, duplicating page walk code _yet again_, porting uffd logic, etc. etc.) But in an ideal world we'd have _one_ place that does this. > > We already discussed in the past that we need a better and more efficient > way to walk page tables. I have part of that on my TODO list, but I'm > getting distracted. Yes I remember an LSF session on this, it's a really obvious area of improvement that stands out at the moment for sure. Having worked several 12+ hour days in a row though recently I can relate to workload making this difficult though :) > > *Inserting* (not walking/modifying existing things as most users to) as done > in this patch is slightly different though, likely "on thing that fits all" > will not apply to all page table walker user cases. Yeah, there's also replace scenarios which then have to do egregious amounts of work to make sure we do everything right, in fact there's duplicates of this in mm/madvise.c *grumble grumble*. > > -- > Cheers, > > David / dhildenb > OK so I guess I'll hold off my TODOs on this as you are looking in this area and I trust you :) Cheers!
