lkml.org 
[lkml]   [2022]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory allocation on speculative fastpaths
On Tue 03-05-22 16:15:46, Suren Baghdasaryan wrote:
> On Tue, May 3, 2022 at 11:28 AM Matthew Wilcox <willy@infradead.org> wrote:
[...]
> > rcu_read_lock();
> > vma = vma_lookup();
> > if (down_read_trylock(&vma->sem)) {
> > rcu_read_unlock();
> > } else {
> > rcu_read_unlock();
> > mmap_read_lock(mm);
> > vma = vma_lookup();
> > down_read(&vma->sem);
> > }
> >
> > ... and we then execute the page table allocation under the protection of
> > the vma->sem.
> >
> > At least, that's what I think we agreed to yesterday.
>
> Honestly, I don't remember discussing vma->sem at all.

This is the rangelocking approach that is effectivelly per-VMA. So that
should help with the most simplistic case where the mmap contention is
not on the same VMAs which should be the most common case (e.g. faulting
from several threads while there is mmap happening in the background).

There are cases where this could be too coarse of course and RCU would
be a long term plan. The above seems easy enough and still probably good
enough for most cases so a good first step.
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2022-05-04 01:46    [W:2.140 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site