Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754027AbcKRT5k convert rfc822-to-8bit (ORCPT ); Fri, 18 Nov 2016 14:57:40 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:33032 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751965AbcKRT5j (ORCPT ); Fri, 18 Nov 2016 14:57:39 -0500 From: "Aneesh Kumar K.V" To: =?utf-8?B?SsOpcsO0bWU=?= Glisse , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: John Hubbard , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Jatin Kumar , Mark Hairgrove , Sherry Cheung , Subhash Gutti Subject: Re: [HMM v13 16/18] mm/hmm/migrate: new memory migration helper for use with device memory In-Reply-To: <1479493107-982-17-git-send-email-jglisse@redhat.com> References: <1479493107-982-1-git-send-email-jglisse@redhat.com> <1479493107-982-17-git-send-email-jglisse@redhat.com> Date: Sat, 19 Nov 2016 01:27:28 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16111819-0040-0000-0000-000001E5905E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006100; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00782531; UDB=6.00377620; IPR=6.00560001; BA=6.00004892; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013371; XFM=3.00000011; UTC=2016-11-18 19:57:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16111819-0041-0000-0000-000005D89BD6 Message-Id: <87k2c0muhj.fsf@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-18_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611180334 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3753 Lines: 131 Jérôme Glisse writes: > This patch add a new memory migration helpers, which migrate memory > backing a range of virtual address of a process to different memory > (which can be allocated through special allocator). It differs from > numa migration by working on a range of virtual address and thus by > doing migration in chunk that can be large enough to use DMA engine > or special copy offloading engine. > > Expected users are any one with heterogeneous memory where different > memory have different characteristics (latency, bandwidth, ...). As > an example IBM platform with CAPI bus can make use of this feature > to migrate between regular memory and CAPI device memory. New CPU > architecture with a pool of high performance memory not manage as > cache but presented as regular memory (while being faster and with > lower latency than DDR) will also be prime user of this patch. > > Migration to private device memory will be usefull for device that > have large pool of such like GPU, NVidia plans to use HMM for that. > .............. >+ > +static int hmm_collect_walk_pmd(pmd_t *pmdp, > + unsigned long start, > + unsigned long end, > + struct mm_walk *walk) > +{ > + struct hmm_migrate *migrate = walk->private; > + struct mm_struct *mm = walk->vma->vm_mm; > + unsigned long addr = start; > + spinlock_t *ptl; > + hmm_pfn_t *pfns; > + int pages = 0; > + pte_t *ptep; > + > +again: > + if (pmd_none(*pmdp)) > + return 0; > + > + split_huge_pmd(walk->vma, pmdp, addr); > + if (pmd_trans_unstable(pmdp)) > + goto again; > + > + pfns = &migrate->pfns[(addr - migrate->start) >> PAGE_SHIFT]; > + ptep = pte_offset_map_lock(mm, pmdp, addr, &ptl); > + arch_enter_lazy_mmu_mode(); > + > + for (; addr < end; addr += PAGE_SIZE, pfns++, ptep++) { > + unsigned long pfn; > + swp_entry_t entry; > + struct page *page; > + hmm_pfn_t flags; > + bool write; > + pte_t pte; > + > + pte = ptep_get_and_clear(mm, addr, ptep); > + if (!pte_present(pte)) { > + if (pte_none(pte)) > + continue; > + > + entry = pte_to_swp_entry(pte); > + if (!is_device_entry(entry)) { > + set_pte_at(mm, addr, ptep, pte); > + continue; > + } > + > + flags = HMM_PFN_DEVICE | HMM_PFN_UNADDRESSABLE; > + page = device_entry_to_page(entry); > + write = is_write_device_entry(entry); > + pfn = page_to_pfn(page); > + > + if (!(page->pgmap->flags & MEMORY_MOVABLE)) { > + set_pte_at(mm, addr, ptep, pte); > + continue; > + } > + > + } else { > + pfn = pte_pfn(pte); > + page = pfn_to_page(pfn); > + write = pte_write(pte); > + flags = is_zone_device_page(page) ? HMM_PFN_DEVICE : 0; > + } > + > + /* FIXME support THP see hmm_migrate_page_check() */ > + if (PageTransCompound(page)) > + continue; > + > + *pfns = hmm_pfn_from_pfn(pfn) | HMM_PFN_MIGRATE | flags; > + *pfns |= write ? HMM_PFN_WRITE : 0; > + migrate->npages++; > + get_page(page); > + > + if (!trylock_page(page)) { > + set_pte_at(mm, addr, ptep, pte); > + } else { > + pte_t swp_pte; > + > + *pfns |= HMM_PFN_LOCKED; > + > + entry = make_migration_entry(page, write); > + swp_pte = swp_entry_to_pte(entry); > + if (pte_soft_dirty(pte)) > + swp_pte = pte_swp_mksoft_dirty(swp_pte); > + set_pte_at(mm, addr, ptep, swp_pte); > + > + page_remove_rmap(page, false); > + put_page(page); > + pages++; > + } Can you explain this. What does a failure to lock means here. Also why convert the pte to migration entries here ? We do that in try_to_unmap right ? > + } > + > + arch_leave_lazy_mmu_mode(); > + pte_unmap_unlock(ptep - 1, ptl); > + > + /* Only flush the TLB if we actually modified any entries */ > + if (pages) > + flush_tlb_range(walk->vma, start, end); > + > + return 0; > +} >