lkml.org 
[lkml]   [2008]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v1][PATCH]page_fault retry with NOPAGE_RETRY
Nick Piggin wrote:
> On Thu, Nov 27, 2008 at 11:22:57AM -0800, Mike Waychison wrote:
>> Nick Piggin wrote:
>>> On Thu, Nov 27, 2008 at 11:00:07AM +0100, Peter Zijlstra wrote:
>>> pagemap_read looks like it can use get_user_pages_fast. The smaps and
>>> clear_refs stuff might have been nicer if they could work on ranges
>>> like pagemap. Then they could avoid mmap_sem as well (although maps
>>> would need to be sampled and take mmap_sem I guess).
>>>
>>> One problem with dropping mmap_sem is that it hurts priority/fairness.
>>> And it opens a bit of a (maybe theoretical but not something to completely
>>> ignore) forward progress hole AFAIKS. If mmap_sem is very heavily
>>> contended, then the refault is going to take a while to get through,
>>> and then the page might get reclaimed etc).
>> Right, this can be an issue. The way around it should be to minimize
>> the length of time any single lock holder can sit on it. Compared to
>> what we have today with:
>>
>> - sleep in major fault with read lock held,
>> - enqueue writer behind it,
>> - and make all other faults wait on the rwsem
>>
>> The retry logic seems to be a lot better for forward progress.
>
> The whole reason why you have the latency is because it is
> guaranteeing forward progress for everyone. The retry logic
> may work out better in that situation, but it does actually
> open a starvation hole.
>

Right. In practice though, we haven't seen this cause a problem (and is
why we'll only allow the path to retry once).

Do you have any suggestions on how we could plug this hole? Perhaps we
could pin a reference to the page in the vm_fault structure across the
retry?


\
 
 \ /
  Last update: 2008-11-28 23:51    [W:0.177 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site