[ Fixed email for Joao Martins. ] Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Mon, Jun 6, 2022 at 1:22 PM Ankur Arora <ankur.a.arora@xxxxxxxxxx> wrote: [snip] > So I really don't like this series. A *lot* of it comes from that > horrible process_huge_page() model, and the whole model is just wrong > and pointless. You're literally trying to fix the mess that that > function is, but you're keeping the fundamental problem around. > > The whole *point* of your patch-set is to use non-temporal stores, > which makes all the process_huge_page() things entirely pointless, and > only complicates things. > > And even if we don't use non-temporal stores, that process_huge_page() > thing makes for trouble for any "rep stos/movs" implementation that > might actualyl do a better job if it was just chunked up in bigger > chunks. This makes sense to me. There is a lot of unnecessary machinery around process_huge_page() and this series adds more of it. For highmem and page-at-a-time archs we would need to keep some of the same optimizations (via the common clear/copy_user_highpages().) Still that rids the arch code from pointless constraints as you say below. > Yes, yes, you probably still want to chunk that up somewhat due to > latency reasons, but even then architectures might as well just make > their own decisions, rather than have the core mm code make one > clearly bad decision for them. Maybe chunking it up in bigger chunks > than one page. Right. Or doing the whole contiguous area in one or a few chunks chunks, and then touching the faulting cachelines towards the end. > Maybe an architecture could do even more radical things like "let's > just 'rep stos' for the whole area, but set a special thread flag that > causes the interrupt return to break it up on return to kernel space". > IOW, the "latency fix" might not even be about chunking it up, it > might look more like our exception handling thing. When I was thinking about this earlier, I had a vague inkling of setting a thread flag and defer writes to the last few cachelines for just before returning to user-space. Can you elaborate a little about what you are describing above? > So I really think that crapectomy should be the first thing you do, > and that should be that first part of "extends the clear_page() > machinery to also handle extents larger than a single page" Ack that. And, thanks for the detailed comments. -- ankur
