search for: put_dev_pagemaps

On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote: > There is only a single place where the pgmap is passed over a function > call, so replace it with local variables in the places where we deal > with the pgmap. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > mm/hmm.c | 62 ++++++++++++++++++++++++-------------------------------- > 1 file

There is only a single place where the pgmap is passed over a function call, so replace it with local variables in the places where we deal with the pgmap. Signed-off-by: Christoph Hellwig <hch at lst.de> --- mm/hmm.c | 62 ++++++++++++++++++++++++-------------------------------- 1 file changed, 27 insertions(+), 35 deletions(-) diff --git a/mm/hmm.c b/mm/hmm.c index

...gt; > That said, this seems to want a better mechanism to determine "pfn is > > ZONE_DEVICE". > > So I guess this patch is fine for now, and once you provide a better > mechanism we can switch over to it? What about the version I sent to just get rid of all the strange put_dev_pagemaps while scanning? Odds are good we will work with only a single pagemap, so it makes some sense to cache it once we find it? diff --git a/mm/hmm.c b/mm/hmm.c index 9a908902e4cc38..4e30128c23a505 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -497,10 +497,6 @@ static int hmm_vma_handle_pmd(struct mm_walk *w...

On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote: > Section alignment constraints somewhat save us here. The only example > I can think of a PMD not containing a uniform pgmap association for > each pte is the case when the pgmap overlaps normal dram, i.e. shares > the same 'struct memory_section' for a given span. Otherwise, distinct > pgmaps arrange to manage

On Wed, Aug 7, 2019 at 10:45 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote: > > There is only a single place where the pgmap is passed over a function > > call, so replace it with local variables in the places where we deal > > with the pgmap. > > > > Signed-off-by: Christoph Hellwig

On Wed, Aug 07, 2019 at 11:47:22AM -0700, Dan Williams wrote: > > Unrelated to this patch, but what is the point of getting checking > > that the pgmap exists for the page and then immediately releasing it? > > This code has this pattern in several places. > > > > It feels racy > > Agree, not sure what the intent is here. The only other reason call >

Hi Jérôme, Ben, Felix and Jason, below is a series against the hmm tree which cleans up various minor bits and allows HMM_MIRROR to be built on all architectures. Diffstat: 11 files changed, 94 insertions(+), 210 deletions(-) A git tree is also available at: git://git.infradead.org/users/hch/misc.git hmm-cleanups.2 Gitweb:

On Wed, Aug 7, 2019 at 11:59 PM Christoph Hellwig <hch at lst.de> wrote: > > On Wed, Aug 07, 2019 at 11:47:22AM -0700, Dan Williams wrote: > > > Unrelated to this patch, but what is the point of getting checking > > > that the pgmap exists for the page and then immediately releasing it? > > > This code has this pattern in several places. > > > >

...want a better mechanism to determine "pfn is > > > ZONE_DEVICE". > > > > So I guess this patch is fine for now, and once you provide a better > > mechanism we can switch over to it? > > What about the version I sent to just get rid of all the strange > put_dev_pagemaps while scanning? Odds are good we will work with only > a single pagemap, so it makes some sense to cache it once we find it? Yes, if the scan is over a single pmd then caching it makes sense.

...> ZONE_DEVICE". > > > > > > > > So I guess this patch is fine for now, and once you provide a better > > > > mechanism we can switch over to it? > > > > > > What about the version I sent to just get rid of all the strange > > > put_dev_pagemaps while scanning? Odds are good we will work with only > > > a single pagemap, so it makes some sense to cache it once we find it? > > > > Yes, if the scan is over a single pmd then caching it makes sense. > > Quite frankly an easier an better solution is to remove the page...

Hi Jérôme, Ben, Felxi and Jason, below is a series against the hmm tree which cleans up various minor bits and allows HMM_MIRROR to be built on all architectures. Diffstat: 7 files changed, 81 insertions(+), 171 deletions(-) A git tree is also available at: git://git.infradead.org/users/hch/misc.git hmm-cleanups Gitweb:

On 11/9/20 1:14 AM, Christoph Hellwig wrote: > On Fri, Nov 06, 2020 at 01:26:50PM -0800, Ralph Campbell wrote: >> >> On 11/6/20 12:03 AM, Christoph Hellwig wrote: >>> I hate the extra pin count magic here. IMHO we really need to finish >>> off the series to get rid of the extra references on the ZONE_DEVICE >>> pages first. >> >> First, thanks

ZONE_DEVICE struct pages have an extra reference count that complicates the code for put_page() and several places in the kernel that need to check the reference count to see that a page is not being used (gup, compaction, migration, etc.). Clean up the code so the reference count doesn't need to be treated specially for device private pages, leaving DAX as still being a special case.

...> > > > > So I guess this patch is fine for now, and once you provide a better > > > > > > mechanism we can switch over to it? > > > > > > > > > > What about the version I sent to just get rid of all the strange > > > > > put_dev_pagemaps while scanning? Odds are good we will work with only > > > > > a single pagemap, so it makes some sense to cache it once we find it? > > > > > > > > Yes, if the scan is over a single pmd then caching it makes sense. > > > > > > Quite frankly...

On Fri, Nov 06, 2020 at 01:26:50PM -0800, Ralph Campbell wrote: > > On 11/6/20 12:03 AM, Christoph Hellwig wrote: >> I hate the extra pin count magic here. IMHO we really need to finish >> off the series to get rid of the extra references on the ZONE_DEVICE >> pages first. > > First, thanks for the review comments. > > I don't like the extra refcount

Stub out the whole function when CONFIG_TRANSPARENT_HUGEPAGE is not set to make the function easier to read. Signed-off-by: Christoph Hellwig <hch at lst.de> --- mm/hmm.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/mm/hmm.c b/mm/hmm.c index 4d3bd41b6522..f4e90ea5779f 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -455,13 +455,10 @@ static inline uint64_t

On Tue, Jul 30, 2019 at 08:52:01AM +0300, Christoph Hellwig wrote: > Stub out the whole function when CONFIG_TRANSPARENT_HUGEPAGE is not set > to make the function easier to read. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > mm/hmm.c | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/mm/hmm.c b/mm/hmm.c > index

Stub out the whole function when CONFIG_TRANSPARENT_HUGEPAGE is not set to make the function easier to read. Signed-off-by: Christoph Hellwig <hch at lst.de> --- mm/hmm.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/mm/hmm.c b/mm/hmm.c index 5e7afe685213..4aa7135f1094 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -455,13 +455,10 @@ static inline

...ne "pfn is > > > > ZONE_DEVICE". > > > > > > So I guess this patch is fine for now, and once you provide a better > > > mechanism we can switch over to it? > > > > What about the version I sent to just get rid of all the strange > > put_dev_pagemaps while scanning? Odds are good we will work with only > > a single pagemap, so it makes some sense to cache it once we find it? > > Yes, if the scan is over a single pmd then caching it makes sense. Quite frankly an easier an better solution is to remove the pagemap lookup as HMM user...

...> > > > > > > > > So I guess this patch is fine for now, and once you provide a better > > > > > mechanism we can switch over to it? > > > > > > > > What about the version I sent to just get rid of all the strange > > > > put_dev_pagemaps while scanning? Odds are good we will work with only > > > > a single pagemap, so it makes some sense to cache it once we find it? > > > > > > Yes, if the scan is over a single pmd then caching it makes sense. > > > > Quite frankly an easier an better solut...