> I don't think we only care about x86_64? Should other archs have the same > issue as long as there's the hardware young bit? > > Even without it, it'll affect page reclaim logic too, and that's also not > x86 only. Okay, reading the cover letter and looking at the code my understanding was that x86-64 is the real focus. >> >>> >>> Besides I actually have a question on the anon exclusive bit in the swap >>> pte: since we have that anyway, why we need a specific migration type for >>> anon exclusive pages? Can it be simply read migration entries with anon >>> exclusive bit set? >> >> Not before all arch support pte_swp_mkexclusive/pte_swp_exclusive/. >> >> As pte_swp_mkexclusive/pte_swp_exclusive/ only applies to actual swap >> PTEs, you could even reuse that bit for migration entries and get at >> alteast the most relevant 64bit architectures supported easily. > > Yes, but I think having two mechanisms for the single problem can confuse > people. > It would be one bit with two different meanings depending on the swp type. > IIUC the swap bit is already defined in major archs anyway, and since anon > exclusive bit is best-effort (or am I wrong?..), I won't worry too much on It kind-of is best effort, but the goal is to have all archs support it. ... just like the young bit here? > archs outside x86/arm/ppc/s390 on having anon exclusive bit lost during > migrations, because afaict the whole swap type of ANON_EXCLUSIVE_READ is > only servicing that very minority.. which seems to be a pity to waste the I have a big item on my todo list to support all, but I have different priorities right now. If there is no free bit, simply steal one from the offset ... which is the same thing your approach would do, just in a different way, no? > swp type on all archs even if the archs defined swp pte bits just for anon > exclusive. Why do we care? We walk about one type not one bit. -- Thanks, David / dhildenb
