Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758068Ab2JZJec (ORCPT ); Fri, 26 Oct 2012 05:34:32 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:59471 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752149Ab2JZJe2 (ORCPT ); Fri, 26 Oct 2012 05:34:28 -0400 Date: Fri, 26 Oct 2012 10:34:08 +0100 From: Will Deacon To: Ni zhan Chen Cc: "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "mhocko@suse.cz" , "peterz@infradead.org" , "akpm@linux-foundation.org" , Chris Metcalf , "Kirill A. Shutemov" , Andrea Arcangeli Subject: Re: [PATCH v3] mm: thp: Set the accessed flag for old pages on access fault. Message-ID: <20121026093407.GD20914@mudshark.cambridge.arm.com> References: <1351183471-14710-1-git-send-email-will.deacon@arm.com> <508A2B8B.7020608@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <508A2B8B.7020608@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2190 Lines: 51 On Fri, Oct 26, 2012 at 07:19:55AM +0100, Ni zhan Chen wrote: > On 10/26/2012 12:44 AM, Will Deacon wrote: > > On x86 memory accesses to pages without the ACCESSED flag set result in the > > ACCESSED flag being set automatically. With the ARM architecture a page access > > fault is raised instead (and it will continue to be raised until the ACCESSED > > flag is set for the appropriate PTE/PMD). > > > > For normal memory pages, handle_pte_fault will call pte_mkyoung (effectively > > setting the ACCESSED flag). For transparent huge pages, pmd_mkyoung will only > > be called for a write fault. > > > > This patch ensures that faults on transparent hugepages which do not result > > in a CoW update the access flags for the faulting pmd. > > Could you write changlog? >From v2? I included something below my SoB. The code should do exactly the same as before, it's just rebased onto next so that I can play nicely with Peter's patches. > > > > Cc: Chris Metcalf > > Cc: Kirill A. Shutemov > > Cc: Andrea Arcangeli > > Signed-off-by: Will Deacon > > --- > > > > Ok chaps, I rebased this thing onto today's next (which basically > > necessitated a rewrite) so I've reluctantly dropped my acks and kindly > > ask if you could eyeball the new code, especially where the locking is > > concerned. In the numa code (do_huge_pmd_prot_none), Peter checks again > > that the page is not splitting, but I can't see why that is required. > > > > Cheers, > > > > Will > > Could you explain why you not call pmd_trans_huge_lock to confirm the > pmd is splitting or stable as Andrea point out? The way handle_mm_fault is now structured after the numa changes means that we only enter the huge pmd page aging code if the entry wasn't splitting before taking the lock, so it seemed a bit gratuitous to jump through those hoops again in pmd_trans_huge_lock. Will -- 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/