[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJu=L58O147YQJyODD8MFtdvQ6+TSG6gi6qGySgH3EigP32MrQ@mail.gmail.com>
Date: Wed, 17 Sep 2014 10:00:32 -0700
From: Andres Lagar-Cavilla <andreslc@...gle.com>
To: Gleb Natapov <gleb@...nel.org>
Cc: Radim Krčmář <rkrcmar@...hat.com>,
Gleb Natapov <gleb@...hat.com>, Rik van Riel <riel@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Mel Gorman <mgorman@...e.de>,
Andy Lutomirski <luto@...capital.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Sasha Levin <sasha.levin@...cle.com>,
Jianyu Zhan <nasa4836@...il.com>,
Paul Cassella <cassella@...y.com>,
Hugh Dickins <hughd@...gle.com>,
Peter Feiner <pfeiner@...gle.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] kvm: Faults which trigger IO release the mmap_sem
On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov <gleb@...nel.org> wrote:
> On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
>> 2014-09-17 13:26+0300, Gleb Natapov:
>> > For async_pf_execute() you do not need to even retry. Next guest's page fault
>> > will retry it for you.
>>
>> Wouldn't that be a waste of vmentries?
> This is how it will work with or without this second gup. Page is not
> mapped into a shadow page table on this path, it happens on a next fault.
The point is that the gup in the async pf completion from the work
queue will not relinquish the mmap semaphore. And it most definitely
should, given that we are likely looking at swap/filemap.
Andres
>
> --
> Gleb.
--
Andres Lagar-Cavilla | Google Kernel Team | andreslc@...gle.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists