Re: [PATCH v1 2/5] userfaultfd: introduce access-likely mode for common operations

[David Hildenbrand <david@redhat.com>]

> 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