Re: unuse_pte: set pte dirty if the page is dirty

[Christoph Lameter <clameter@engr.sgi.com>]

On Tue, 28 Feb 2006, Hugh Dickins wrote:

> I shared Andrew's unease, but couldn't put my finger on any actual
> problem.  But in the course of writing a much more hesitant reply,
> came to realize the patch is just bogus.  Did you ever measure any
> improvement from it, on any architecture?  0% is my estimate.

I have not actually measured it. What I see though are dirty pages
referred to by ptes that are not dirty after page migration. The
ptes were dirty before migration.
 
> I was recommending that the VM_WRITE test be replaced by a pte_write
> test, when I remembered that vm_page_prot on any vma which contains
> anonymous pages (excepting the very rare Linus ptrace case) will not
> grant write access (see comment above unuse_pte).  So if this pte is
> actually written to afterwards, you'll have to handle a write fault
> on it, won't you?  No saving whatever from presetting dirty - or am
> I misunderstanding how the architecture closest to your heart works?

Yuck....

> I guess you could work around that by checking mapcount+swapcount
> and granting write access in the common uniquely-mapped case; but
> swapoff has never bothered to do so.  Unless you can come up with
> convincing numbers, I'd say let it die - halve the time of a
> significant migration testcase?  yes, we should make a patch;
> shave 5% off it?  no, for peace of mind let's not worry about it.

Right. Thanks. At least I can now justify the vanishing of the 
dirty bit from the ptes.

Hmm.. Maybe ultimately we need to have a special mechanism (like Marcelo's 
migration cache) to remove ptes and add ptes during page migration. That 
could take this into account but it seems that such a mechanism better be
separate from the common swap code.

--
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>