Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161232AbbKEMyY (ORCPT ); Thu, 5 Nov 2015 07:54:24 -0500 Received: from relay.parallels.com ([195.214.232.42]:59394 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032442AbbKEMyV (ORCPT ); Thu, 5 Nov 2015 07:54:21 -0500 Date: Thu, 5 Nov 2015 15:53:54 +0300 From: Vladimir Davydov To: "Kirill A. Shutemov" CC: "Kirill A. Shutemov" , Andrew Morton , Andrea Arcangeli , Hugh Dickins , Naoya Horiguchi , Sasha Levin , Minchan Kim , , Subject: Re: [PATCH 4/4] mm: prepare page_referenced() and page_idle to new THP refcounting Message-ID: <20151105125354.GE29259@esperanza> References: <1446564375-72143-1-git-send-email-kirill.shutemov@linux.intel.com> <1446564375-72143-5-git-send-email-kirill.shutemov@linux.intel.com> <20151105091013.GC29259@esperanza> <20151105092459.GC7614@node.shutemov.name> <20151105120726.GD29259@esperanza> <20151105123606.GE7614@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20151105123606.GE7614@node.shutemov.name> X-ClientProxiedBy: US-EXCH2.sw.swsoft.com (10.255.249.46) To MSK-EXCH1.sw.swsoft.com (10.67.48.55) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2039 Lines: 68 On Thu, Nov 05, 2015 at 02:36:06PM +0200, Kirill A. Shutemov wrote: > On Thu, Nov 05, 2015 at 03:07:26PM +0300, Vladimir Davydov wrote: > > @@ -849,30 +836,23 @@ static int page_referenced_one(struct page *page, struct vm_area_struct *vma, > > if (pmd_page(*pmd) != page) > > goto unlock_pmd; > > > > - if (vma->vm_flags & VM_LOCKED) { > > - pra->vm_flags |= VM_LOCKED; > > - ret = SWAP_FAIL; /* To break the loop */ > > - goto unlock_pmd; > > - } > > - > > - if (pmdp_clear_flush_young_notify(vma, address, pmd)) > > - referenced++; > > - spin_unlock(ptl); > > + pte = (pte_t *)pmd; > > pmd_t and pte_t are not always compatible. We shouldn't pretend they are. > And we shouldn't use pte_unmap_unlock() to unlock pmd table. Out of curiosity, is it OK that __page_check_address can call pte_unmap_unlock on pte returned by huge_pte_offset, which isn't really pte, but pmd or pud? > > What about interface like this (I'm not sure about helper's name): > > void page_check_address_transhuge(struct page *page, struct mm_struct *mm, > unsigned long address, > pmd_t **pmdp, pte_t **ptep, > spinlock_t **ptlp); > > page_check_address_transhuge(page, mm, address, &pmd, &pte, &ptl); > if (pmd) { > /* handle pmd... */ > } else if (pte) { > /* handle pte... */ > } else { > return SWAP_AGAIN; > } > > /* common stuff */ > > if (pmd) > spin_unlock(ptl); > else > pte_unmap_unlock(pte, ptl); spin_unlock(ptl); if (pte) pte_unmap(pte); would look neater IMO. Other than that, I think it's OK. At least, it looks better and less error-prone than duplicating such a huge chunk of code IMO. Thanks, Vladimir > > /* ... */ > > The helper shouldn't set pmd if the page is tracked to pte. -- 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/