Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 25 May 2023 22:31:15 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Steven Sistare <steven.sistare@oracle.com>
Cc:     Khalid Aziz <khalid.aziz@oracle.com>, akpm@linux-foundation.org,
        david@redhat.com, ying.huang@intel.com,
        mgorman@techsingularity.net, baolin.wang@linux.alibaba.com,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Khalid Aziz <khalid@kernel.org>
Subject: Re: [PATCH v4] mm, compaction: Skip all non-migratable pages during
 scan
Message-ID: <ZG/To8Z3StoVoenU@casper.infradead.org>
References: <20230525191507.160076-1-khalid.aziz@oracle.com>
 <ZG+99h3zg7POIits@casper.infradead.org>
 <ee093583-71c3-51ba-980f-0facb03b0e23@oracle.com>
 <ZG/I7tYY4uV/32hP@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZG/I7tYY4uV/32hP@casper.infradead.org>
Precedence: bulk

On Thu, May 25, 2023 at 09:45:34PM +0100, Matthew Wilcox wrote:
> > > Isn't "long term pinning" the wrong description of the problem?  Long term
> > > pins suggest to me FOLL_LONGTERM.  I think this is simple short term
> > > pins that we care about here.
> > 
> > vfio pins are held for a long time - Steve
> 
> So this is a third sense of "pinned pages" that is neither what
> filesystems nor the mm means by pinned pages, but whatever it is that
> vfio means by pinned pages?  If only "pin" weren't such a desirable
> word.  Can somebody explain to me in small words what a vfio pin looks
> like because I've tried reading vfio_iommu_type1_pin_pages() and I
> don't recognise anything there that looks like pinning in either of
> the other two senses.

Oh, I think I found it!  pin_user_pages_remote() is called by
vaddr_get_pfns().  If these are the pages you're concerned about,
then the efficient way to do what you want is simply to call
folio_maybe_dma_pinned().  Far more efficient than the current mess
of total_mapcount().