> On Aug 24, 2018, at 6:39 PM, Shady Issa <shady.issa@xxxxxxxxxx> wrote: > > > > On 08/24/2018 03:40 AM, Laurent Dufour wrote: >> On 22/08/2018 16:46, Davidlohr Bueso wrote: >>> On Wed, 22 Aug 2018, Shady Issa wrote: >>> >>>> Hi Davidlohr, >>>> >>>> I am interested in the idea of using range locks to replace mm_sem. I wanted to >>>> start trying out using more fine-grained ranges instead of the full range >>>> acquisitions >>>> that are used in this patch (https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2018_2_4_235&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Q-zBmi7tP5HosTvB8kUZjTYqSFMRtxg-kOQa59-zx9I&m=ZCN6CnHZsYyZ_V0nWMSZgLmp-GobwtrhI3Wx8UAIQuY&s=LtbMxuR2njAX0dm3L2lNQKvztbnLTfKjBd-S20cDPbE&e=). However, it >>>> does not >>>> seem straight forward to me how this is possible. >>>> >>>> First, the ranges that can be defined before acquiring the range lock based >>>> on the >>>> caller's input(i.e. ranges supplied by mprotect, mmap, munmap, etc.) are >>>> oblivious of >>>> the underlying VMAs. Two non-overlapping ranges can fall within the same VMA and >>>> thus should not be allowed to run concurrently in case they are writes. >>> Yes. This is a _big_ issue with range locking the addr space. I have yet >>> to find a solution other than delaying vma modifying ops to avoid the races, >>> which is fragile. Obviously locking the full range in such scenarios cannot >>> be done either. >> I think the range locked should be aligned to the underlying VMA plus one page >> on each side to prevent that VMA to be merged. How would one find the underlying VMA for the range lock acquisition? Looks like that would require searching the rb-tree (currently protected by mm_sem), and that search has to be synchronized with concurrent tree modifications. Regards, — Alex >> But this raises a concern with the VMA merging mechanism which tends to limit >> the number of VMAs and could lead to a unique VMA, limiting the advantage of a >> locking based on the VMA's boundaries. > To do so, the current merge implementation should be changed so that > it does not access VMAs beyond the locked range, right? Also, this will > not stop a merge from happening in case of a range spanning two VMAs > for example. >> >>>> Second, even if ranges from the caller function are aligned with VMAs, the >>>> extent of the >>>> effect of operation is unknown. It is probable that an operation touching one >>>> VMA will >>>> end up performing modifications to the VMAs rbtree structure due to splits, >>>> merges, etc., >>>> which requires the full range acquisition and is unknown beforehand. >>> Yes, this is similar to the above as well. >>> >>>> I was wondering if I am missing something with this thought process, because >>>> with the >>>> current givings, it seems to me that range locks will boil down to just r/w >>>> semaphore. >>>> I would also be very grateful if you can point me to any more recent >>>> discussions regarding >>>> the use of range locks after this patch from February. >>> You're on the right page. >>> >>> Thanks, >>> Davidlohr >>> >
