Re: [PATCH 1/3] mm: tracking shared dirty pages

[Christoph Lameter <clameter@sgi.com>]

On Tue, 30 May 2006, David Howells wrote:

> > If set_page_dirty cannot reserve the page then we know that some severe
> > action is required. The FS method set_page_dirty() could:
> 
> But by the time set_page_dirty() is called, it's too late as the code
> currently stands.  We've already marked the PTE writable and dirty.  The
> page_mkwrite() op is called _first_.

We are in set_page_dirty and this would be part of set_page_dirty 
processing.

> > 2. Track down all processes that use the mapping (or maybe less
> 
> That's bad, even if you restrict it to those that have MAP_SHARED and
> PROT_WRITE set.  They should not be terminated if they haven't attempted to
> write to the mapping.

Its bad but the out of space situation is an exceptional situation. We do 
similar contortions when we run out of memory space. As I said: One can 
track down the processes that have dirtied the pte to the page in question 
and just terminate those and remove the page.

> What's wrong with my suggestion anyway?

Adds yet another method with functionality that for the most part 
is the same as set_page_dirty().

The advantage of such a method seems to be that it reserves filesystem 
space for pages that could potentially be written to. This allows the 
filesystem to accurately deal with out of space situations (a very rare 
condition. Is this really justifiable?). Maybe having already reserved 
space could speed up the real dirtying of pages?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/