Messages in this thread | | | Date | Tue, 23 Apr 2024 12:18:44 +0200 | Subject | Re: [RFC PATCH v1 0/4] Reduce cost of ptep_get_lockless on arm64 | From | David Hildenbrand <> |
| |
On 23.04.24 12:15, Ryan Roberts wrote: > Hi David, > > Sorry for the slow reply on this; its was due to a combination of thinking a bit > more about the options here and being out on holiday. >
No worries, there are things more important in life than ptep_get_lockless() :D
>> (1) seems like the easiest thing to do. > > Yes, I'm very much in favour of easy. > >> >>> >>> Perhaps its useful to enumerate why we dislike the current ptep_get_lockless()? >> >> Well, you sent that patch series with "that aims to reduce the cost and >> complexity of ptep_get_lockless() for arm64". (2) and (3) would achieve that. :) > > Touche! I'd half forgotten that we were having this conversation in the context > of this series! > > I guess your ptep_get_gup_fast() approach is very similar to > ptep_get_lockless_norecency()... So we are back to the beginning :)
Except that it would be limited to GUP-fast :)
> > But ultimately I've come to the conclusion that it is easy to reason about the > current arm64 ptep_get_lockless() implementation and see that its correct. The > other options both have their drawbacks.
Yes.
> > Yes, there is a loop in the current implementation that would be nice to get rid > of, but I don't think it is really any worse than the cmpxchg loops we already > have in other helpers. > > I'm not planning to persue this any further. Thanks for the useful discussion > (as always).
Make sense to me. let's leave it as is for the time being. (and also see if a GUP-fast user that needs precise dirty/accessed actually gets real)
-- Cheers,
David / dhildenb
| |