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=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,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 32FB4C433E0 for ; Wed, 17 Feb 2021 20:25:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 64E6464E63 for ; Wed, 17 Feb 2021 20:25:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64E6464E63 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C84936B0006; Wed, 17 Feb 2021 15:25:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C0CAC6B006C; Wed, 17 Feb 2021 15:25:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFA6A6B006E; Wed, 17 Feb 2021 15:25:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) by kanga.kvack.org (Postfix) with ESMTP id 998356B0006 for ; Wed, 17 Feb 2021 15:25:24 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4D5BBAC0D for ; Wed, 17 Feb 2021 20:25:24 +0000 (UTC) X-FDA: 77828889768.03.tree09_47094f12764f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 27DBE28A4E9 for ; Wed, 17 Feb 2021 20:25:24 +0000 (UTC) X-HE-Tag: tree09_47094f12764f X-Filterd-Recvd-Size: 8001 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Wed, 17 Feb 2021 20:25:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613593522; 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: in-reply-to:in-reply-to:references:references; bh=hZtRJeUML7NHUfQaoih4ryjpEijORracEaJufXohTpE=; b=cc8vViWY2QCgC5YaU/p1FluPbyHCTL/18aHudvKUjuK8crgjn+n7yv8Ihod6nXmykYf3JL QGS4AAkr8bHycQANPmsbIxriEC/xVF/zyxhEs5i0vts8w1oYePAIWtRX20gxV39/r20u+9 m751s3FzqHYnDZQJjt/oY6A72pgYl9M= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-184-6ViJsqrGNnGgsvwrrWJF1Q-1; Wed, 17 Feb 2021 15:25:21 -0500 X-MC-Unique: 6ViJsqrGNnGgsvwrrWJF1Q-1 Received: by mail-qt1-f197.google.com with SMTP id k28so8576530qtu.17 for ; Wed, 17 Feb 2021 12:25:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hZtRJeUML7NHUfQaoih4ryjpEijORracEaJufXohTpE=; b=SVSrv/HgEULzIWylVToO9AB08CBVy6NvljZabRVHCBHK9eETICJyG0a9xhvqoMbzLK Yk5vxqYVON6X7HzbNkcSZM3EIdGV4fDEq4TCFv38HPiGuoV60Mmus2mdvBvWYWlPIMoN cVsw3wbMerBimi/xyZR2WzZXhWzYnZZ5gyvHul3REfWl4QpTRUP/iy0pgQCVMUjowZbP 1P6ub+FhhviBYHgfC2DUj9K2gY1SRQvLB4npLZ3CPy0jtV7hn+vBLm9jkcLWcLXX8bBR 99nfC9VDWNNP2VifxvkRYAWTA4Y0fGMvFDJ0psogtNoVkMfLzLI0qUbrgEy4czcFsGuU OUJw== X-Gm-Message-State: AOAM533sZ7Wy/G4nwZ1ZuIY2seDKqW1MQxD2YG/UUS1RYvwbTt2hbjdT EXO9aHeAGyS36sAqC6+hqtnj7TFnER/6jWVVNh6RvADnVBUwBh/s3bD9TwutOpWgr9liKoP5NcM GekmOSGNXxQ8= X-Received: by 2002:a37:e4d:: with SMTP id 74mr997927qko.109.1613593520564; Wed, 17 Feb 2021 12:25:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJzh1hgcn30UQ1Pzk5/L6ZLtIbXgncB61U4mq0qYkBmtccAv/ChS4Cjoj7zOPZwFtCtLxtOTeQ== X-Received: by 2002:a37:e4d:: with SMTP id 74mr997909qko.109.1613593520273; Wed, 17 Feb 2021 12:25:20 -0800 (PST) Received: from xz-x1 (bras-vprn-toroon474qw-lp130-20-174-93-89-182.dsl.bell.ca. [174.93.89.182]) by smtp.gmail.com with ESMTPSA id r80sm2436111qke.97.2021.02.17.12.25.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Feb 2021 12:25:19 -0800 (PST) Date: Wed, 17 Feb 2021 15:25:18 -0500 From: Peter Xu To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, shu wang , Axel Rasmussen , Andrea Arcangeli , Heiko Carstens , Alexey Dobriyan , Matthew Wilcox , Michel Lespinasse , Andrew Morton Subject: Re: [RFC PATCH 5/5] mm proc/task_mmu.c: add hugetlb specific routine for clear_refs Message-ID: <20210217202518.GA19238@xz-x1> References: <20210211000322.159437-1-mike.kravetz@oracle.com> <20210211000322.159437-6-mike.kravetz@oracle.com> MIME-Version: 1.0 In-Reply-To: <20210211000322.159437-6-mike.kravetz@oracle.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 Wed, Feb 10, 2021 at 04:03:22PM -0800, Mike Kravetz wrote: > There was is no hugetlb specific routine for clearing soft dirty and > other referrences. The 'default' routines would only clear the > VM_SOFTDIRTY flag in the vma. > > Add new routine specifically for hugetlb vmas. > > Signed-off-by: Mike Kravetz > --- > fs/proc/task_mmu.c | 110 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 110 insertions(+) > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 829b35016aaa..f06cf9b131a8 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -1116,6 +1116,115 @@ static inline void clear_soft_dirty_pmd(struct vm_area_struct *vma, > } > #endif > > +#ifdef CONFIG_HUGETLB_PAGE > +static inline bool huge_pte_is_pinned(struct vm_area_struct *vma, > + unsigned long addr, pte_t pte) > +{ > + struct page *page; > + > + if (likely(!atomic_read(&vma->vm_mm->has_pinned))) > + return false; > + page = pte_page(pte); > + if (!page) > + return false; > + return page_maybe_dma_pinned(page); > +} > + > +static int clear_refs_hugetlb_range(pte_t *ptep, unsigned long hmask, > + unsigned long addr, unsigned long end, > + struct mm_walk *walk) > +{ > + struct clear_refs_private *cp = walk->private; > + struct vm_area_struct *vma = walk->vma; > + struct hstate *h = hstate_vma(walk->vma); > + unsigned long adj_start = addr, adj_end = end; > + spinlock_t *ptl; > + pte_t old_pte, pte; > + > + /* > + * clear_refs should only operate on complete vmas. Therefore, > + * values passed here should be huge page aligned and huge page > + * size in length. Quick validation before taking any action in > + * case upstream code is changed. > + */ > + if ((addr & hmask) != addr || end - addr != huge_page_size(h)) { > + WARN_ONCE(1, "%s passed unaligned address\n", __func__); > + return 1; > + } I wouldn't worry too much on the interface change - The one who will change the interface should guarantee all existing hooks will still work, isn't it? :) It's slightly confusing to me on why "clear_refs should only operate on complete vmas" is related to the check, though. > + > + ptl = huge_pte_lock(hstate_vma(vma), walk->mm, ptep); > + > + /* Soft dirty and pmd sharing do not mix */ Right, this seems to be a placeholder for unsharing code. Though maybe we can do that earlier in pre_vma() hook? That should be per-vma rather than handling one specific huge page here, hence more efficient imho. this reminded me that I should also better move hugetlb_unshare_all_pmds() of my other patch into hugetlb.c, so that this code can call it. Currently it's a static function in userfaultfd.c. > + > + pte = huge_ptep_get(ptep); > + if (!pte_present(pte)) > + goto out; > + if (unlikely(is_hugetlb_entry_hwpoisoned(pte))) > + goto out; > + > + if (cp->type == CLEAR_REFS_SOFT_DIRTY) { Maybe move this check into clear_refs_test_walk()? We can bail out earlier if: (is_vm_hugetlb_page(vma) && (type != CLEAR_REFS_SOFT_DIRTY)) > + if (huge_pte_is_pinned(vma, addr, pte)) > + goto out; Out of topic of this patchset, but it's definitely a pity that we can't track soft dirty for pinned pages. Currently the assumption of the pte code path is: "if this page can be DMA written then we won't know whether data changed after all, then tracking dirty is meaningless", however that's prone to change when new hardwares coming, say, IOMMU could start to trap DMA writes already. But again that's another story.. and we should just follow what we do with non-hugetlbfs for sure here, until some day if we'd like to revive soft dirty tracking with pinned pages. > + > + /* > + * soft dirty and pmd sharing do not work together as > + * per-process is tracked in ptes, and pmd sharing allows > + * processed to share ptes. We unshare any pmds here. > + */ > + adjust_range_if_pmd_sharing_possible(vma, &adj_start, &adj_end); Ideally when reach here, huge pmd sharing won't ever exist, right? Then do we still need to adjust the range at all? Thanks, -- Peter Xu