Re: [RFC][PATCH] tracking dirty pages in shared mappings

[Nick Piggin <piggin@cyberone.com.au>]

Nick Piggin wrote:
> Peter Zijlstra wrote:
> 
>> On Sat, 2006-05-06 at 23:47 +1000, Nick Piggin wrote:
>>
>>
>>> Yep. Let's not distract from getting the basic mechanism working though.
>>> balance_dirty_pages would be patch 2..n ;)
>>>
>>
>> Attached are both a new version of the shared_mapping_dirty patch, and
>> balance_dirty_pages; to be applied in that order.
>> It makes my testcase survive and not OOM like it used to.
>>
> 
> Looks OK. I wonder if test_clear_page_dirty could skip the page_wrprotect
> entirely? It would speed up cases like truncate that don't care. OTOH, it
> looks like several filesystems do not use clear_page_dirty_for_io where
> they possibly should be...
> 
> Perhaps you could consolidate both checks into test_set_page_writeback()?

Actually, you'll skip the slow path of taking the lock most of the
times in situations like truncate because it will bail out after the
page_mapped check. So doing anything further is probably a premature
optimisation at this stage.

Nick

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>