On Mon, Jun 7, 2021 at 6:49 AM Joao Martins <joao.m.martins@xxxxxxxxxx> wrote: [..] > > Given all of the above I'm wondering if there should be a new > > "compound specific" flavor of this routine rather than trying to > > cleverly inter mingle the old path with the new. This is easier > > because you have already done the work in previous patches to break > > this into helpers. So just have memmap_init_zone_device() do it the > > "old" way and memmap_init_compound() handle all the tail page init + > > optimizations. > > > I can separate it out, should be easier to follow. > > Albeit just a note, I think memmap_init_compound() should be the new normal as metadata > more accurately represents what goes on the page tables. That's regardless of > vmemmap-based gains, and hence why my train of thought was to not separate it. > > After this series, all devmap pages where @geometry matches @align will have compound > pages be used instead. And we enable that in device-dax as first user (in the next patch). > altmap or not so far just differentiates on the uniqueness of struct pages as the former > doesn't reuse base pages that only contain tail pages and consequently makes us initialize > all tail struct pages. I think combining the cases into a common central routine makes the code that much harder to maintain. A small duplication cost is worth it in my opinion to help readability / maintainability.
