On Fri, Jul 28, 2023 at 09:40:54PM +0200, David Hildenbrand wrote:
> Hmm. So three alternatives I see:
>
> 1) Use FOLL_FORCE in follow_page() to unconditionally disable protnone
> checks. Alternatively, have an internal FOLL_NO_PROTNONE flag if we
> don't like that.
>
> 2) Revert the commit and reintroduce unconditional FOLL_NUMA without
> FOLL_FORCE.
>
> 3) Have a FOLL_NUMA that callers like KVM can pass.
I'm afraid 3) means changing numa balancing to opt-in, probably no-go for
any non-kvm gup users as that could start to break there, even if making
smaps/follow_page happy again.
I keep worrying 1) on FOLL_FORCE abuse.
So I keep my vote on 2).
Thanks,
--
Peter Xu
On 28.07.23 21:50, Peter Xu wrote:
> On Fri, Jul 28, 2023 at 09:40:54PM +0200, David Hildenbrand wrote:
>> Hmm. So three alternatives I see:
>>
>> 1) Use FOLL_FORCE in follow_page() to unconditionally disable protnone
>> checks. Alternatively, have an internal FOLL_NO_PROTNONE flag if we
>> don't like that.
>>
>> 2) Revert the commit and reintroduce unconditional FOLL_NUMA without
>> FOLL_FORCE.
>>
>> 3) Have a FOLL_NUMA that callers like KVM can pass.
>
> I'm afraid 3) means changing numa balancing to opt-in, probably no-go for
> any non-kvm gup users as that could start to break there, even if making
> smaps/follow_page happy again.
>
> I keep worrying 1) on FOLL_FORCE abuse.
>
> So I keep my vote on 2).
Linus had a point that we can nowadays always set FOLL_NUMA, even with
FOLL_FORCE.
... so maybe we want to let GUP always set FOLL_NUMA (even with
FOLL_FORCE) and follow_page() never set FOLL_NUMA.
That would at least decouple FOLL_NUMA from FOLL_FORCE.
--
Cheers,
David / dhildenb