From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 28 Feb 2006 08:06:02 -0800 (PST) From: Christoph Lameter Subject: Re: unuse_pte: set pte dirty if the page is dirty In-Reply-To: Message-ID: References: <20060227175324.229860ca.akpm@osdl.org> <20060227182137.3106a4cf.akpm@osdl.org> <20060227203923.24e9336c.akpm@osdl.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Hugh Dickins Cc: Andrew Morton , linux-mm@kvack.org List-ID: 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: email@kvack.org