Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3014353ybt; Mon, 22 Jun 2020 12:40:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZzucEi2AfDeClN0lrC+JHNLPDtYUv277Z+U8oBqQDNvw5lhnTx84OP6PnZd8AMZvZ9Twm X-Received: by 2002:a17:906:e2d5:: with SMTP id gr21mr16531325ejb.219.1592854833160; Mon, 22 Jun 2020 12:40:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592854833; cv=none; d=google.com; s=arc-20160816; b=gGipQUGUdzZWNh/Oh1t61PECirGy8vNxeGHpZJDBEJuPCbvE+bMsLF2rp36n3+4LGu oih0DRmkQMPLxUeGQKFwdfVhRnE04cg0HrZHQZudqzpGNPaQiNeosgXVvW6aBrJJpPkW pfg4KN2eHkfKExpegQNuQqrQaUo24j6aCL2v8tr4oblNDOIHTZlUlhf4PCO7ATnzganG dBiH6fOEggmk1XDV9tVJkCcYsvk62D8hZsABcofhRP8mXDDrGsHWuqNWv9VeTy3sIBzZ rcvPyYtysQP1JOARc8R4C25QIzwoa8J/NVCyHnbyCJHKGizGyrmAJCJ1VfO6CcYNGO/e dKOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=k92wmBgrGAE346s5tJGKtF1T6WINWYI3KFBqOeO8Nlw=; b=a+Yzyy54o6pTQPHcVvOuyaBOw+WgRPThIywP+4Fzmg9KF1o0TbaK0UVZX70b6hyws/ QlJb34p0t594BoFAP8PHEVG/jbAN0/wRkTCO1DDh8sD8k5R1IXhda/ZJn5jKIWvfO8XH ZhGxjdN9qVD81Esx+Bz5DCa9/BngnlN68oNhwL4VkuCGYr9u/EoTuSH9C78060Ozw7I3 BDDX5merMk1JAULeY7PqyErX4xzTVCElUiDERuMVyqP48TYFtqL7gAvYUc3Af0vcEuXE uijLzuczRfU83qFYUAJJlWtzj8Lp1Jv8afDV7IXfJddeFZeyketwHrQtdjuFp3/SwUeX sEcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=XbZZVsKW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k1si9224985eja.313.2020.06.22.12.40.09; Mon, 22 Jun 2020 12:40:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=XbZZVsKW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728388AbgFVTgU (ORCPT + 99 others); Mon, 22 Jun 2020 15:36:20 -0400 Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:16392 "EHLO hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728150AbgFVTgT (ORCPT ); Mon, 22 Jun 2020 15:36:19 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Mon, 22 Jun 2020 12:36:07 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Mon, 22 Jun 2020 12:36:19 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Mon, 22 Jun 2020 12:36:19 -0700 Received: from rcampbell-dev.nvidia.com (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jun 2020 19:36:13 +0000 Subject: Re: [PATCH 13/16] mm: support THP migration to device private memory To: Zi Yan CC: , , , , , Jerome Glisse , "John Hubbard" , Christoph Hellwig , "Jason Gunthorpe" , Ben Skeggs , Andrew Morton , Shuah Khan References: <20200619215649.32297-1-rcampbell@nvidia.com> <20200619215649.32297-14-rcampbell@nvidia.com> From: Ralph Campbell X-Nvconfidentiality: public Message-ID: Date: Mon, 22 Jun 2020 12:36:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1592854567; bh=k92wmBgrGAE346s5tJGKtF1T6WINWYI3KFBqOeO8Nlw=; h=X-PGP-Universal:Subject:To:CC:References:From:X-Nvconfidentiality: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=XbZZVsKWFDMXu+mngjFYiRn2RbQAIcVJJlSDUvc/OgLFsfWagoAzSycdRPS23bc+u 90cSRi4HCzcajweccikNKZxCcES+coy0DPkVoindh/tvK5sDM3W7s35U+bSdDmOWtG NUmEHT+sZ8dRU9gRd8hVyhwMbe/dIXf2MJIlLzMb+79CGSPHSCVdY6IelcEL8R0Ul/ 1aGjl+A5NgFU9OVnK42g+u+Gq29eihRRkGlXbO5YE/gN3yzCqijZe0sHWBN0hzB/DP vJiXwvziXSBB31zCiRD/2WvlgYOdEZlyYGFb33xirIoc2J6wqlsqpKxoo0L7oCqA7S hPj1k8FBFDMWg== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/21/20 4:20 PM, Zi Yan wrote: > On 19 Jun 2020, at 17:56, Ralph Campbell wrote: > >> Support transparent huge page migration to ZONE_DEVICE private memory. >> A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to >> indicate the huge page was fully mapped by the CPU. >> Export prep_compound_page() so that device drivers can create huge >> device private pages after calling memremap_pages(). >> >> Signed-off-by: Ralph Campbell >> --- >> include/linux/migrate.h | 1 + >> include/linux/mm.h | 1 + >> mm/huge_memory.c | 30 ++++-- >> mm/internal.h | 1 - >> mm/memory.c | 10 +- >> mm/memremap.c | 9 +- >> mm/migrate.c | 226 ++++++++++++++++++++++++++++++++-------- >> mm/page_alloc.c | 1 + >> 8 files changed, 226 insertions(+), 53 deletions(-) >> >> diff --git a/include/linux/migrate.h b/include/linux/migrate.h >> index 3e546cbf03dd..f6a64965c8bd 100644 >> --- a/include/linux/migrate.h >> +++ b/include/linux/migrate.h >> @@ -166,6 +166,7 @@ static inline int migrate_misplaced_transhuge_page(struct mm_struct *mm, >> #define MIGRATE_PFN_MIGRATE (1UL << 1) >> #define MIGRATE_PFN_LOCKED (1UL << 2) >> #define MIGRATE_PFN_WRITE (1UL << 3) >> +#define MIGRATE_PFN_COMPOUND (1UL << 4) >> #define MIGRATE_PFN_SHIFT 6 >> >> static inline struct page *migrate_pfn_to_page(unsigned long mpfn) >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index dc7b87310c10..020b9dd3cddb 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -932,6 +932,7 @@ static inline unsigned int page_shift(struct page *page) >> } >> >> void free_compound_page(struct page *page); >> +void prep_compound_page(struct page *page, unsigned int order); >> >> #ifdef CONFIG_MMU >> /* >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> index 78c84bee7e29..25d95f7b1e98 100644 >> --- a/mm/huge_memory.c >> +++ b/mm/huge_memory.c >> @@ -1663,23 +1663,35 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, >> } else { >> struct page *page = NULL; >> int flush_needed = 1; >> + bool is_anon = false; >> >> if (pmd_present(orig_pmd)) { >> page = pmd_page(orig_pmd); >> + is_anon = PageAnon(page); >> page_remove_rmap(page, true); >> VM_BUG_ON_PAGE(page_mapcount(page) < 0, page); >> VM_BUG_ON_PAGE(!PageHead(page), page); >> } else if (thp_migration_supported()) { >> swp_entry_t entry; >> >> - VM_BUG_ON(!is_pmd_migration_entry(orig_pmd)); >> entry = pmd_to_swp_entry(orig_pmd); >> - page = pfn_to_page(swp_offset(entry)); >> + if (is_device_private_entry(entry)) { >> + page = device_private_entry_to_page(entry); >> + is_anon = PageAnon(page); >> + page_remove_rmap(page, true); >> + VM_BUG_ON_PAGE(page_mapcount(page) < 0, page); >> + VM_BUG_ON_PAGE(!PageHead(page), page); >> + put_page(page); > > Why do you hide this code behind thp_migration_supported()? It seems that you just need > pmd swap entry not pmd migration entry. Also the condition is not consistent with the code > in __handle_mm_fault(), in which you handle is_device_private_entry() directly without > checking thp_migration_support(). Good point, I think "else if (thp_migration_supported())" should be "else if (is_pmd_migration_entry(orig_pmd))" since if the PMD *is* a device private or migration entry, then it should be handled and the VM_BUG_ON() should be that thp_migration_supported() is true (or maybe remove the VM_BUG_ON?). > Do we need to support split_huge_pmd() if a page is migrated to device? Any new code > needed in split_huge_pmd()? I was thinking that any CPU usage of the device private page would cause it to be migrated back to system memory as a whole PMD/PUD page but I'll double check. At least there should be a check that the page isn't a device private page.