From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C50C4C433E1 for ; Wed, 24 Mar 2021 17:45:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A470C619EC for ; Wed, 24 Mar 2021 17:45:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A470C619EC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2F31F6B0294; Wed, 24 Mar 2021 13:45:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A3336B02C0; Wed, 24 Mar 2021 13:45:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F5FB6B02C2; Wed, 24 Mar 2021 13:45:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id E4D836B0294 for ; Wed, 24 Mar 2021 13:45:55 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A51F4182E1117 for ; Wed, 24 Mar 2021 17:45:55 +0000 (UTC) X-FDA: 77955495870.18.B90C1CB Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf27.hostedemail.com (Postfix) with ESMTP id DA4DB80192DB for ; Wed, 24 Mar 2021 17:45:52 +0000 (UTC) Received: by mail-ed1-f45.google.com with SMTP id h10so28572273edt.13 for ; Wed, 24 Mar 2021 10:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gGg9bkmQmUrJEoYO//o+38WT2vp4tDvJ1YauvHLK3w0=; b=FvQlkmFH+tOQEZcfLr3Wsp0O5iLofV5GNtUxR5JyPoM5RLG5vHO0fVqWiayt+ShEiq 6fOcX+/MeA/YjC57p8CPqmLsGiGYJLmRra8KGCVinVIoroyCsik+dyIWDBQTzm+1KveI 3phrbMjz/WSkCRSI41RGGf+W0S888ZEPvbBpYLoK3GfRyXt5qIb2rnZx9IzUiipPH6jt zozhTgF1kG6BbfK756qY10AQSO1h33cgsHI0KI8CSfl3kX3LQVP7SGifZKvRhMAeV4d9 n+fPrenlEA+w78JYAcQjAowrJAfquHk2wnR7aqBvBIpXV+h1NRlYakr+HiETBpvDrqwm drfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gGg9bkmQmUrJEoYO//o+38WT2vp4tDvJ1YauvHLK3w0=; b=DD0mzm7rvyzhIo6pI442sYkkaP9zaTuaBHO/eSuCwP+gPlSm89gNecVOKVcyXnCNN6 EscapQ3e5Pvn1JVZBhka/U4558A7w36bk7WqOCm1fvoOomP7THMrUCGyXmewKMxV/9k4 Dh8gziSmY+dYwJgSryYMBidbFAsZ7dLLzZ/GSUzsFloJ8SfaaObAVnrtLYUud3vQqKzH m0hX9vvnPCILvCzRhOqPAEv+nHLXvNjb00NrJ7jAx8y7Hzagey9YVQFDAdlxLzyTqZyj pu1AtMxGcn7NFIqDbysPUD6rgXftYJ8wO5uDYmKJa8NHvxB+Z1Ka7qZjevXrIS8humHb 8mjg== X-Gm-Message-State: AOAM5331CilbCvgm67QacIQuhGdN000O8M/Txsf7/ZsaKpSljN8bMi/I 5nRbZSQZ/qbDGSVBClBdpKg06U4jJ8OJ5sJsphhTMA== X-Google-Smtp-Source: ABdhPJzYwYdMUsSiaziQc4bOwaRP/eIf8tsvN1+MbwfleMPszchzvYZawTUvBNwx7NAPJcu1DDlQkg6IjQ7Aaw/eheI= X-Received: by 2002:aa7:dd05:: with SMTP id i5mr4696265edv.300.1616607953325; Wed, 24 Mar 2021 10:45:53 -0700 (PDT) MIME-Version: 1.0 References: <161604048257.1463742.1374527716381197629.stgit@dwillia2-desk3.amr.corp.intel.com> <161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com> <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com> In-Reply-To: <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com> From: Dan Williams Date: Wed, 24 Mar 2021 10:45:42 -0700 Message-ID: Subject: Re: [PATCH 3/3] mm/devmap: Remove pgmap accounting in the get_user_pages_fast() path To: Joao Martins Cc: Jason Gunthorpe , Christoph Hellwig , Shiyang Ruan , Vishal Verma , Dave Jiang , Ira Weiny , Matthew Wilcox , Jan Kara , Andrew Morton , david , linux-fsdevel , Linux Kernel Mailing List , Linux MM , linux-nvdimm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: DA4DB80192DB X-Stat-Signature: 1t4brjeposdm3auynk7dtqz3ie8qmf3k Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=mail-ed1-f45.google.com; client-ip=209.85.208.45 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616607952-285253 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Mar 18, 2021 at 3:02 AM Joao Martins wrote: > > On 3/18/21 4:08 AM, Dan Williams wrote: > > Now that device-dax and filesystem-dax are guaranteed to unmap all user > > mappings of devmap / DAX pages before tearing down the 'struct page' > > array, get_user_pages_fast() can rely on its traditional synchronization > > method "validate_pte(); get_page(); revalidate_pte()" to catch races with > > device shutdown. Specifically the unmap guarantee ensures that gup-fast > > either succeeds in taking a page reference (lock-less), or it detects a > > need to fall back to the slow path where the device presence can be > > revalidated with locks held. > > [...] > > > @@ -2087,21 +2078,26 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end, > > #endif /* CONFIG_ARCH_HAS_PTE_SPECIAL */ > > > > #if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE) > > + > > static int __gup_device_huge(unsigned long pfn, unsigned long addr, > > unsigned long end, unsigned int flags, > > struct page **pages, int *nr) > > { > > int nr_start = *nr; > > - struct dev_pagemap *pgmap = NULL; > > > > do { > > - struct page *page = pfn_to_page(pfn); > > + struct page *page; > > + > > + /* > > + * Typically pfn_to_page() on a devmap pfn is not safe > > + * without holding a live reference on the hosting > > + * pgmap. In the gup-fast path it is safe because any > > + * races will be resolved by either gup-fast taking a > > + * reference or the shutdown path unmapping the pte to > > + * trigger gup-fast to fall back to the slow path. > > + */ > > + page = pfn_to_page(pfn); > > > > - pgmap = get_dev_pagemap(pfn, pgmap); > > - if (unlikely(!pgmap)) { > > - undo_dev_pagemap(nr, nr_start, flags, pages); > > - return 0; > > - } > > SetPageReferenced(page); > > pages[*nr] = page; > > if (unlikely(!try_grab_page(page, flags))) { > > So for allowing FOLL_LONGTERM[0] would it be OK if we used page->pgmap after > try_grab_page() for checking pgmap type to see if we are in a device-dax > longterm pin? So, there is an effort to add a new pte bit p{m,u}d_special to disable gup-fast for huge pages [1]. I'd like to investigate whether we could use devmap + special as an encoding for "no longterm" and never consult the pgmap in the gup-fast path. [1]: https://lore.kernel.org/linux-mm/a1fa7fa2-914b-366d-9902-e5b784e8428c@shipmail.org/