Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3009613pxb; Thu, 10 Feb 2022 10:08:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJxfI2xxCSp3br71f1roAIAfKR7JF7ZHH5Bk639vaDhYTQgB9acfzStg9ZyfbViFfX4hvHSZ X-Received: by 2002:aa7:db8f:: with SMTP id u15mr9902134edt.36.1644516516670; Thu, 10 Feb 2022 10:08:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644516516; cv=none; d=google.com; s=arc-20160816; b=FTHMpys6MwJgAnLKtE/xQnqcxZwp2AgxNvODlxuxSpHBtZDJ/vWYxAVnLnxxEQ4ePt /OoIbBxQnkhpAbyeN/HhKT+UZ7VfLM03hb/CIbhLHEepAdJDlNoPB3roPVWMxFtmdVqG vtyzK7YG1G3QoepHIH602PsWnGz0GXlsWrVhCH3tuDc+y9OoNYbVPUZ6xl03d9QDcOtA gbuvgklWO/Y/pax3W+y2raHeRahtV8gyc595JqODG91hNm+m/c2bXsxqJWIq/RdSTA70 WzmOwitOldfOIYpb9g7vBcJbRBvyDvnuyS4B++nL8PrbT0DhxkQzsAgwiTH2JhT2p6Nl o+TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:dkim-signature; bh=voWjPDpl6rgnyPEWRLZY/zlAv4le197CBv6xEpGwtjU=; b=0kQDvZAHaQEPpOd68SFtGyxQ+S1Z08Dw3Uss9A5+jQOnrqxzbsEADUSDns8uCyrmuO GPIZ05/GUyYDkgILA4dmOOuD8MWmV+wgIK8LAPJ81meUltuesvERJ2HRsFmfh7n1dkFm wqzGrxB0TIwctomcaT4sIjZHXJDfBxWM0vytDbj5Lh/zDlF6AWet7S1RNZA3TsmR6oQV OuXdozi/nEohyr8FTyv5zEoQRWpx0zLYb1vJtRsP1CZOK4B9/SPHebL5+OeZXF8CWkkb iONC2a/DjF++Iz6B2vs33DbEwl2h111K3wOmSMQyiP3zBar7sgn/gCIk5rwqdUSos0ZZ pw4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WB96oGju; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 24si12406924ejg.895.2022.02.10.10.08.06; Thu, 10 Feb 2022 10:08:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WB96oGju; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235635AbiBJLrk (ORCPT + 99 others); Thu, 10 Feb 2022 06:47:40 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:45784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234873AbiBJLrj (ORCPT ); Thu, 10 Feb 2022 06:47:39 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C705EC5 for ; Thu, 10 Feb 2022 03:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644493659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=voWjPDpl6rgnyPEWRLZY/zlAv4le197CBv6xEpGwtjU=; b=WB96oGjuHGfveKtbdv/IrjyJfi+ap9b7otdpbxCQg93zlRrsrMpoyHHz98cV0xdSLmQcZQ nzyhhgSBeRSezVRGA45xhvXSfzZhlw3y63sLUKGUv2YzkVNSvNFPGDS6Kmdh17hFjfIC6n K9cAtwktTtvyABpk7mt7JOZzGFwwmEA= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-216-jPmxuoxvOp2pvBhtKhZVSw-1; Thu, 10 Feb 2022 06:47:39 -0500 X-MC-Unique: jPmxuoxvOp2pvBhtKhZVSw-1 Received: by mail-wm1-f72.google.com with SMTP id bg16-20020a05600c3c9000b0034bea12c043so4204525wmb.7 for ; Thu, 10 Feb 2022 03:47:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=voWjPDpl6rgnyPEWRLZY/zlAv4le197CBv6xEpGwtjU=; b=v85PovikznlniJG4lyoVFe4nuilcfdqPB/vURgXcCCKm0mlZRflJHC0KaYtY4f6oss kKAVzy9+xn8yaHU8W2nxPpSGFecrk7ij4J6ySIcElEQZdDgIGHe+xkoRc9s207hBQIed ph3LGDNK3EHgOk004JjTfji8dB8MTGgM37zvQKoKT0IkcJOtRj+7421OIDJru5KD/tdh LGXbThHeiqMqHMs+gbCzdxIAENuxh/bIRSIxCc9BX2tPkhmodlh8SW+UkZzChoZuh5J0 iBSrpGN6MihhiXioM9E5BMIdHra3E5H7Fq6BMHBkSdd5Niv9bMEKanOc8QyTTskX3+yC /e/w== X-Gm-Message-State: AOAM533cwmimodLG0onYq/VIyprA33v23KIWsCD4cDyOZsGrAhkcqp53 H9TZPNA22lt+6+nGRr6iMku1gntThJz3RGQD7U0LW5Q2bKz4totQmvmH7ZXltxqjMZV/nrm8+0T i8GyIWU8NlgHEV/D1KXW66Q== X-Received: by 2002:a7b:c778:: with SMTP id x24mr1808294wmk.181.1644493657672; Thu, 10 Feb 2022 03:47:37 -0800 (PST) X-Received: by 2002:a7b:c778:: with SMTP id x24mr1808265wmk.181.1644493657358; Thu, 10 Feb 2022 03:47:37 -0800 (PST) Received: from ?IPV6:2003:cb:c70b:f900:7b04:69ec:2caf:3b42? (p200300cbc70bf9007b0469ec2caf3b42.dip0.t-ipconnect.de. [2003:cb:c70b:f900:7b04:69ec:2caf:3b42]) by smtp.gmail.com with ESMTPSA id h6sm1323620wmq.26.2022.02.10.03.47.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Feb 2022 03:47:36 -0800 (PST) Message-ID: Date: Thu, 10 Feb 2022 12:47:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v2 2/3] mm/gup.c: Migrate device coherent pages when pinning instead of failing Content-Language: en-US To: Alistair Popple , akpm@linux-foundation.org, linux-mm@kvack.org Cc: Felix.Kuehling@amd.com, rcampbell@nvidia.com, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, hch@lst.de, jgg@nvidia.com, jglisse@redhat.com, willy@infradead.org, alex.sierra@amd.com, jhubbard@nvidia.com References: <9117b387-3c73-0236-51d1-9e6baf43b34e@redhat.com> <1894939.704c7Wv018@nvdebian> From: David Hildenbrand Organization: Red Hat In-Reply-To: <1894939.704c7Wv018@nvdebian> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 10.02.22 12:39, Alistair Popple wrote: > On Thursday, 10 February 2022 9:53:38 PM AEDT David Hildenbrand wrote: >> On 07.02.22 05:26, Alistair Popple wrote: >>> Currently any attempts to pin a device coherent page will fail. This is >>> because device coherent pages need to be managed by a device driver, and >>> pinning them would prevent a driver from migrating them off the device. >>> >>> However this is no reason to fail pinning of these pages. These are >>> coherent and accessible from the CPU so can be migrated just like >>> pinning ZONE_MOVABLE pages. So instead of failing all attempts to pin >>> them first try migrating them out of ZONE_DEVICE. >>> >>> Signed-off-by: Alistair Popple >>> Acked-by: Felix Kuehling >>> --- >>> >>> Changes for v2: >>> >>> - Added Felix's Acked-by >>> - Fixed missing check for dpage == NULL >>> >>> mm/gup.c | 105 ++++++++++++++++++++++++++++++++++++++++++++++++++------ >>> 1 file changed, 95 insertions(+), 10 deletions(-) >>> >>> diff --git a/mm/gup.c b/mm/gup.c >>> index 56d9577..5e826db 100644 >>> --- a/mm/gup.c >>> +++ b/mm/gup.c >>> @@ -1861,6 +1861,60 @@ struct page *get_dump_page(unsigned long addr) >>> >>> #ifdef CONFIG_MIGRATION >>> /* >>> + * Migrates a device coherent page back to normal memory. Caller should have a >>> + * reference on page which will be copied to the new page if migration is >>> + * successful or dropped on failure. >>> + */ >>> +static struct page *migrate_device_page(struct page *page, >>> + unsigned int gup_flags) >>> +{ >>> + struct page *dpage; >>> + struct migrate_vma args; >>> + unsigned long src_pfn, dst_pfn = 0; >>> + >>> + lock_page(page); >>> + src_pfn = migrate_pfn(page_to_pfn(page)) | MIGRATE_PFN_MIGRATE; >>> + args.src = &src_pfn; >>> + args.dst = &dst_pfn; >>> + args.cpages = 1; >>> + args.npages = 1; >>> + args.vma = NULL; >>> + migrate_vma_setup(&args); >>> + if (!(src_pfn & MIGRATE_PFN_MIGRATE)) >>> + return NULL; >>> + >>> + dpage = alloc_pages(GFP_USER | __GFP_NOWARN, 0); >>> + >>> + /* >>> + * get/pin the new page now so we don't have to retry gup after >>> + * migrating. We already have a reference so this should never fail. >>> + */ >>> + if (dpage && WARN_ON_ONCE(!try_grab_page(dpage, gup_flags))) { >>> + __free_pages(dpage, 0); >>> + dpage = NULL; >>> + } >>> + >>> + if (dpage) { >>> + lock_page(dpage); >>> + dst_pfn = migrate_pfn(page_to_pfn(dpage)); >>> + } >>> + >>> + migrate_vma_pages(&args); >>> + if (src_pfn & MIGRATE_PFN_MIGRATE) >>> + copy_highpage(dpage, page); >>> + migrate_vma_finalize(&args); >>> + if (dpage && !(src_pfn & MIGRATE_PFN_MIGRATE)) { >>> + if (gup_flags & FOLL_PIN) >>> + unpin_user_page(dpage); >>> + else >>> + put_page(dpage); >>> + dpage = NULL; >>> + } >>> + >>> + return dpage; >>> +} >>> + >>> +/* >>> * Check whether all pages are pinnable, if so return number of pages. If some >>> * pages are not pinnable, migrate them, and unpin all pages. Return zero if >>> * pages were migrated, or if some pages were not successfully isolated. >>> @@ -1888,15 +1942,40 @@ static long check_and_migrate_movable_pages(unsigned long nr_pages, >>> continue; >>> prev_head = head; >>> /* >>> - * If we get a movable page, since we are going to be pinning >>> - * these entries, try to move them out if possible. >>> + * Device coherent pages are managed by a driver and should not >>> + * be pinned indefinitely as it prevents the driver moving the >>> + * page. So when trying to pin with FOLL_LONGTERM instead try >>> + * migrating page out of device memory. >>> */ >>> if (is_dev_private_or_coherent_page(head)) { >>> + /* >>> + * device private pages will get faulted in during gup >>> + * so it shouldn't be possible to see one here. >>> + */ >>> WARN_ON_ONCE(is_device_private_page(head)); >>> - ret = -EFAULT; >>> - goto unpin_pages; >>> + WARN_ON_ONCE(PageCompound(head)); >>> + >>> + /* >>> + * migration will fail if the page is pinned, so convert >>> + * the pin on the source page to a normal reference. >>> + */ >>> + if (gup_flags & FOLL_PIN) { >>> + get_page(head); >>> + unpin_user_page(head); >>> + } >>> + >>> + pages[i] = migrate_device_page(head, gup_flags); >> >> For ordinary migrate_pages(), we'll unpin all pages and return 0 so the >> caller will retry pinning by walking the page tables again. >> >> Why can't we apply the same mechanism here? This "let's avoid another >> walk" looks unnecessary complicated to me, but I might be wrong. > > There's no reason we couldn't. I figured we have the page in the right spot > anyway so it was easy to do, and looking at this rebased on top of Christoph's > ZONE_DEVICE refcount simplification I'm not sure it would be any simpler > anyway. > > It would remove the call to try_grab_page(), but we'd still have to return an > error on migration failures whilst also ensuring we putback any non-device > pages that may have been isolated. I might have overlooked something though, > so certainly happy for suggestions. Staring at the code, I was wondering if we could either * build a second list of device coherent pages to migrate and call a migrate_device_pages() bulk function * simply use movable_page_list() and teach migrate_pages() how to handle them. I'd really appreciate as little special casing as possible for the ever growing list of new DEVICE types all over the place. E.g., just staring at fork even before the new device coherent made my head spin. -- Thanks, David / dhildenb