> Fundamentally, access bit has more meaningful context (0 means cold, 1 > means hot), for dirty it's really more a perf thing to me (when clear, > it'll take extra cycles to set it when memory write happens to it; being > clear _may_ help only for the tlb flush example you mentioned but I'm not > fully convinced that's correct). > > Maybe with the to be proposed RFC patch for tlb flush we can know whether > that should be something we can rely on. It'll add more dependency on this > work which I'm sorry to say. It's just that IMHO we should think carefully > for the write-hint because this is a solid new uABI we're talking about. > > The other option is we can introduce the access hint first and think more > on the dirty one (we can always add it when proper). What do you think? > Also, David please chim in anytime if I missed the whole point when you > proposed the idea. Well, if we have an ABI that places pages without further information *why* we're doing that makes us having to guess what to do or what not to do, and I think the zeropage placement is a prime example for that. Personally, I think communicating the intention in forms of hints is something that doesn't leak implementation details into an ABI. So "no planned access" vs. "read_likely" vs. "write_likely" conceptually makes sense to me. As I raised previously, *if* we want to let the user affect the dirty bit setting (1) is then a pure implementation detail. Or whatever else we might want to do. But I also want to raise awareness that architectures that don't have a hw-set dirty bit have to use page faults to mimic dirty tracking. IIRC, s390x is a prime example for that: pte_mkclean() sets the WP bit and marks the page dirty from the write fault. So it's even more expensive than on other architectures. -- Thanks, David / dhildenb
