[lkml]   [2010]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/11] V4: rwsem changes + down_read_critical() proposal
    On Tue, 2010-05-25 at 02:12 -0700, Michel Lespinasse wrote:
    > On Tue, May 25, 2010 at 1:47 AM, Peter Zijlstra <> wrote:
    > > So what happened to those patches that dropped mmap_sem during I/O?
    > Yes, we do have patches trying to release the mmap_sem when a page
    > fault for a file backed VMA blocks on accessing the corresponding
    > file. We have not given up on these, and we intend to try submitting
    > them again. However, these patches do *not* address the case of a page
    > fault blocking while trying to get a free page (i.e. when you get
    > under high memory pressure).

    But I guess they could, right? Simply make the allocation under mmap_sem

    and drop the mmap_sem when that fails.

    > > I really don't like people tinkering with the lock implementations like
    > > this. Nor do I like the naming, stats are in no way _critical_.
    > Critical here refers to the fact that you're not allowed to block
    > while holding the unfairly acquired rwsem.

    We usually call that atomic, your 0/n patch didn't explain any of that.

    Also, do you really think doing something like:

    * Check the vma index is within the range and do
    * sequential scan until m_index.
    vma = NULL;
    if ((unsigned long)l < mm->map_count) {
    vma = mm->mmap;
    while (l-- && vma)
    vma = vma->vm_next;
    goto out;

    with preemption disabled is a _good_ thing?

    People were talking about raising our vma limit of 64k...

     \ /
      Last update: 2010-05-25 11:31    [W:0.025 / U:15.220 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site