On Thu, Jun 15, 2023 at 12:57:19AM -0700, Hugh Dickins wrote:
Probably just trivial collisions in most architectures, which either of us can easily adjust to the other; powerpc likely to be more awkward, but fairly easily resolved; s390 quite a problem. I've so far been unable to post a v2 of my series (and powerpc and s390 were stupidly wrong in the v1), because a good s390 patch is not yet decided - Gerald Schaefer and I are currently working on that, on the s390 list (I took off most Ccs until we are settled and I can post v2). As you have no doubt found yourself, s390 has sophisticated handling of free half-pages already, and I need to add rcu_head usage in there too: it's tricky to squeeze it all in, and ptdesc does not appear to help us in any way (though mostly it's just changing some field names, okay). If ptdesc were actually allowing a flexible structure which architectures could add into, that would (in some future) be nice; but of course at present it's still fitting it all into one struct page, and mandating new restrictions which just make an architecture's job harder.
The intent is to get ptdescs to be dynamically allocated at some point in the ~2-3 years out future when we have finished the folio project ... which is not a terribly helpful thing for me to say. I have three suggestions, probably all dreadful: 1. s390 could change its behaviour to always allocate page tables in pairs. That is, it fills in two pmd_t entries any time it takes a fault in either of them. 2. We could allocate two or four pages at a time for s390 to allocate 2kB pages from. That gives us a lot more space to store RCU heads. 3. We could use s390 as a guinea-pig for dynamic ptdesc allocation. Every time we allocate a struct page, we have a slab cache for an s390-special definition of struct ptdesc, we allocate a ptdesc and store a pointer to that in compound_head. We could sweeten #3 by doing that not just for s390 but also for every configuration which has ALLOC_SPLIT_PTLOCKS today. That would get rid of the ambiguity between "is ptl a pointer or a lock".
But I've no desire to undo powerpc's use of pt_frag_refcount: just warning that we may want to undo any use of it in s390.
I would dearly love ppc & s390 to use the _same_ scheme to solve the same problem.
