lkml.org 
[lkml]   [2023]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock
    On Mon, Jan 16, 2023 at 8:14 PM Matthew Wilcox <willy@infradead.org> wrote:
    >
    > On Mon, Jan 16, 2023 at 11:14:38AM +0000, Hyeonggon Yoo wrote:
    > > > @@ -643,20 +647,28 @@ static inline void vma_write_lock(struct vm_area_struct *vma)
    > > > static inline bool vma_read_trylock(struct vm_area_struct *vma)
    > > > {
    > > > /* Check before locking. A race might cause false locked result. */
    > > > - if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
    > > > + if (vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
    > > > return false;
    > > >
    > > > - if (unlikely(down_read_trylock(&vma->vm_lock->lock) == 0))
    > > > + if (unlikely(!atomic_inc_unless_negative(&vma->vm_lock->count)))
    > > > return false;
    > > >
    > > > + /* If atomic_t overflows, restore and fail to lock. */
    > > > + if (unlikely(atomic_read(&vma->vm_lock->count) < 0)) {
    > > > + if (atomic_dec_and_test(&vma->vm_lock->count))
    > > > + wake_up(&vma->vm_mm->vma_writer_wait);
    > > > + return false;
    > > > + }
    > > > +
    > > > /*
    > > > * Overflow might produce false locked result.
    > > > * False unlocked result is impossible because we modify and check
    > > > * vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq
    > > > * modification invalidates all existing locks.
    > > > */
    > > > - if (unlikely(vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) {
    > > > - up_read(&vma->vm_lock->lock);
    > > > + if (unlikely(vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) {
    > > > + if (atomic_dec_and_test(&vma->vm_lock->count))
    > > > + wake_up(&vma->vm_mm->vma_writer_wait);
    > > > return false;
    > > > }
    > >
    > > With this change readers can cause writers to starve.
    > > What about checking waitqueue_active() before or after increasing
    > > vma->vm_lock->count?
    >
    > I don't understand how readers can starve a writer. Readers do
    > atomic_inc_unless_negative() so a writer can always force readers
    > to fail.

    I think the point here was that if page faults keep occuring and they
    prevent vm_lock->count from reaching 0 then a writer will be blocked
    and there is no reader throttling mechanism (no max time that writer
    will be waiting).

    \
     
     \ /
      Last update: 2023-03-26 23:43    [W:6.495 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site