All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: John Hubbard <jhubbard@nvidia.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, mgorman@suse.de, hpa@zytor.com,
	peterz@infraread.org, aarcange@redhat.com, riel@redhat.com,
	jweiner@redhat.com, torvalds@linux-foundation.org,
	"Mark Hairgrove" <mhairgrove@nvidia.com>,
	"Jatin Kumar" <jakumar@nvidia.com>,
	"Subhash Gutti" <sgutti@nvidia.com>,
	"Lucien Dunning" <ldunning@nvidia.com>,
	"Cameron Buschardt" <cabuschardt@nvidia.com>,
	"Arvind Gopalakrishnan" <arvindg@nvidia.com>,
	"Sherry Cheung" <SCheung@nvidia.com>,
	"Duncan Poole" <dpoole@nvidia.com>,
	"Oded Gabbay" <Oded.Gabbay@amd.com>,
	"Alexander Deucher" <Alexander.Deucher@amd.com>,
	"Andrew Lewycky" <Andrew.Lewycky@amd.com>,
	"Jérôme Glisse" <jglisse@redhat.com>
Subject: Re: [PATCH 2/6] mm: differentiate unmap for vmscan from other unmap.
Date: Mon, 30 Jun 2014 11:58:39 -0400	[thread overview]
Message-ID: <20140630155838.GD1956@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1406292054080.21595@blueforge.nvidia.com>

On Sun, Jun 29, 2014 at 08:58:17PM -0700, John Hubbard wrote:
> On Fri, 27 Jun 2014, Jerome Glisse wrote:
> 
> > From: Jerome Glisse <jglisse@redhat.com>
> > 
> > New code will need to be able to differentiate between a regular unmap and
> > an unmap trigger by vmscan in which case we want to be as quick as possible.
> > 
> > Signed-off-by: Jerome Glisse <jglisse@redhat.com>
> > ---
> >  include/linux/rmap.h | 15 ++++++++-------
> >  mm/memory-failure.c  |  2 +-
> >  mm/vmscan.c          |  4 ++--
> >  3 files changed, 11 insertions(+), 10 deletions(-)
> > 
> > diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> > index be57450..eddbc07 100644
> > --- a/include/linux/rmap.h
> > +++ b/include/linux/rmap.h
> > @@ -72,13 +72,14 @@ struct anon_vma_chain {
> >  };
> >  
> >  enum ttu_flags {
> > -	TTU_UNMAP = 1,			/* unmap mode */
> > -	TTU_MIGRATION = 2,		/* migration mode */
> > -	TTU_MUNLOCK = 4,		/* munlock mode */
> > -
> > -	TTU_IGNORE_MLOCK = (1 << 8),	/* ignore mlock */
> > -	TTU_IGNORE_ACCESS = (1 << 9),	/* don't age */
> > -	TTU_IGNORE_HWPOISON = (1 << 10),/* corrupted page is recoverable */
> > +	TTU_VMSCAN = 1,			/* unmap for vmscan */
> > +	TTU_POISON = 2,			/* unmap for poison */
> > +	TTU_MIGRATION = 4,		/* migration mode */
> > +	TTU_MUNLOCK = 8,		/* munlock mode */
> > +
> > +	TTU_IGNORE_MLOCK = (1 << 9),	/* ignore mlock */
> > +	TTU_IGNORE_ACCESS = (1 << 10),	/* don't age */
> > +	TTU_IGNORE_HWPOISON = (1 << 11),/* corrupted page is recoverable */
> 
> Unless there is a deeper purpose that I am overlooking, I think it would 
> be better to leave the _MLOCK, _ACCESS, and _HWPOISON at their original 
> values. I just can't quite see why they would need to start at bit 9 
> instead of bit 8...

This code change to have various TTU_* be bitflag instead of value. I am
not sure what was the win in that, would need to dig up that patch that
did that. But in all the case i preserve that change here hence starting
at 9.
> 
> >  };
> >  
> >  #ifdef CONFIG_MMU
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index a7a89eb..ba176c4 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -887,7 +887,7 @@ static int page_action(struct page_state *ps, struct page *p,
> >  static int hwpoison_user_mappings(struct page *p, unsigned long pfn,
> >  				  int trapno, int flags, struct page **hpagep)
> >  {
> > -	enum ttu_flags ttu = TTU_UNMAP | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS;
> > +	enum ttu_flags ttu = TTU_POISON | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS;
> >  	struct address_space *mapping;
> >  	LIST_HEAD(tokill);
> >  	int ret;
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 6d24fd6..5a7d286 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1163,7 +1163,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone,
> >  	}
> >  
> >  	ret = shrink_page_list(&clean_pages, zone, &sc,
> > -			TTU_UNMAP|TTU_IGNORE_ACCESS,
> > +			TTU_VMSCAN|TTU_IGNORE_ACCESS,
> >  			&dummy1, &dummy2, &dummy3, &dummy4, &dummy5, true);
> >  	list_splice(&clean_pages, page_list);
> >  	mod_zone_page_state(zone, NR_ISOLATED_FILE, -ret);
> > @@ -1518,7 +1518,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
> >  	if (nr_taken == 0)
> >  		return 0;
> >  
> > -	nr_reclaimed = shrink_page_list(&page_list, zone, sc, TTU_UNMAP,
> > +	nr_reclaimed = shrink_page_list(&page_list, zone, sc, TTU_VMSCAN,
> >  				&nr_dirty, &nr_unqueued_dirty, &nr_congested,
> >  				&nr_writeback, &nr_immediate,
> >  				false);
> > -- 
> > 1.9.0
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> > 
> 
> Other than that, looks good.
> 
> Reviewed-by: John Hubbard <jhubbard@nvidia.com>
> 
> thanks,
> John H.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <j.glisse@gmail.com>
To: John Hubbard <jhubbard@nvidia.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, mgorman@suse.de, hpa@zytor.com,
	peterz@infraread.org, aarcange@redhat.com, riel@redhat.com,
	jweiner@redhat.com, torvalds@linux-foundation.org,
	"Mark Hairgrove" <mhairgrove@nvidia.com>,
	"Jatin Kumar" <jakumar@nvidia.com>,
	"Subhash Gutti" <sgutti@nvidia.com>,
	"Lucien Dunning" <ldunning@nvidia.com>,
	"Cameron Buschardt" <cabuschardt@nvidia.com>,
	"Arvind Gopalakrishnan" <arvindg@nvidia.com>,
	"Sherry Cheung" <SCheung@nvidia.com>,
	"Duncan Poole" <dpoole@nvidia.com>,
	"Oded Gabbay" <Oded.Gabbay@amd.com>,
	"Alexander Deucher" <Alexander.Deucher@amd.com>,
	"Andrew Lewycky" <Andrew.Lewycky@amd.com>,
	"Jérôme Glisse" <jglisse@redhat.com>
Subject: Re: [PATCH 2/6] mm: differentiate unmap for vmscan from other unmap.
Date: Mon, 30 Jun 2014 11:58:39 -0400	[thread overview]
Message-ID: <20140630155838.GD1956@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1406292054080.21595@blueforge.nvidia.com>

On Sun, Jun 29, 2014 at 08:58:17PM -0700, John Hubbard wrote:
> On Fri, 27 Jun 2014, Jérôme Glisse wrote:
> 
> > From: Jérôme Glisse <jglisse@redhat.com>
> > 
> > New code will need to be able to differentiate between a regular unmap and
> > an unmap trigger by vmscan in which case we want to be as quick as possible.
> > 
> > Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
> > ---
> >  include/linux/rmap.h | 15 ++++++++-------
> >  mm/memory-failure.c  |  2 +-
> >  mm/vmscan.c          |  4 ++--
> >  3 files changed, 11 insertions(+), 10 deletions(-)
> > 
> > diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> > index be57450..eddbc07 100644
> > --- a/include/linux/rmap.h
> > +++ b/include/linux/rmap.h
> > @@ -72,13 +72,14 @@ struct anon_vma_chain {
> >  };
> >  
> >  enum ttu_flags {
> > -	TTU_UNMAP = 1,			/* unmap mode */
> > -	TTU_MIGRATION = 2,		/* migration mode */
> > -	TTU_MUNLOCK = 4,		/* munlock mode */
> > -
> > -	TTU_IGNORE_MLOCK = (1 << 8),	/* ignore mlock */
> > -	TTU_IGNORE_ACCESS = (1 << 9),	/* don't age */
> > -	TTU_IGNORE_HWPOISON = (1 << 10),/* corrupted page is recoverable */
> > +	TTU_VMSCAN = 1,			/* unmap for vmscan */
> > +	TTU_POISON = 2,			/* unmap for poison */
> > +	TTU_MIGRATION = 4,		/* migration mode */
> > +	TTU_MUNLOCK = 8,		/* munlock mode */
> > +
> > +	TTU_IGNORE_MLOCK = (1 << 9),	/* ignore mlock */
> > +	TTU_IGNORE_ACCESS = (1 << 10),	/* don't age */
> > +	TTU_IGNORE_HWPOISON = (1 << 11),/* corrupted page is recoverable */
> 
> Unless there is a deeper purpose that I am overlooking, I think it would 
> be better to leave the _MLOCK, _ACCESS, and _HWPOISON at their original 
> values. I just can't quite see why they would need to start at bit 9 
> instead of bit 8...

This code change to have various TTU_* be bitflag instead of value. I am
not sure what was the win in that, would need to dig up that patch that
did that. But in all the case i preserve that change here hence starting
at 9.
> 
> >  };
> >  
> >  #ifdef CONFIG_MMU
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index a7a89eb..ba176c4 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -887,7 +887,7 @@ static int page_action(struct page_state *ps, struct page *p,
> >  static int hwpoison_user_mappings(struct page *p, unsigned long pfn,
> >  				  int trapno, int flags, struct page **hpagep)
> >  {
> > -	enum ttu_flags ttu = TTU_UNMAP | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS;
> > +	enum ttu_flags ttu = TTU_POISON | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS;
> >  	struct address_space *mapping;
> >  	LIST_HEAD(tokill);
> >  	int ret;
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 6d24fd6..5a7d286 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1163,7 +1163,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone,
> >  	}
> >  
> >  	ret = shrink_page_list(&clean_pages, zone, &sc,
> > -			TTU_UNMAP|TTU_IGNORE_ACCESS,
> > +			TTU_VMSCAN|TTU_IGNORE_ACCESS,
> >  			&dummy1, &dummy2, &dummy3, &dummy4, &dummy5, true);
> >  	list_splice(&clean_pages, page_list);
> >  	mod_zone_page_state(zone, NR_ISOLATED_FILE, -ret);
> > @@ -1518,7 +1518,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
> >  	if (nr_taken == 0)
> >  		return 0;
> >  
> > -	nr_reclaimed = shrink_page_list(&page_list, zone, sc, TTU_UNMAP,
> > +	nr_reclaimed = shrink_page_list(&page_list, zone, sc, TTU_VMSCAN,
> >  				&nr_dirty, &nr_unqueued_dirty, &nr_congested,
> >  				&nr_writeback, &nr_immediate,
> >  				false);
> > -- 
> > 1.9.0
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> > 
> 
> Other than that, looks good.
> 
> Reviewed-by: John Hubbard <jhubbard@nvidia.com>
> 
> thanks,
> John H.


  reply	other threads:[~2014-06-30 15:58 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-28  2:00 mm preparatory patches for HMM and IOMMUv2 Jérôme Glisse
2014-06-28  2:00 ` Jérôme Glisse
2014-06-28  2:00 ` [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:49   ` John Hubbard
2014-06-30  3:49     ` John Hubbard
2014-06-30 15:07     ` Jerome Glisse
2014-06-30 15:07       ` Jerome Glisse
2014-06-30 14:41   ` Gabbay, Oded
2014-06-30 14:41     ` Gabbay, Oded
     [not found]     ` <019CCE693E457142B37B791721487FD91806B836-0nO7ALo/ziwxlywnonMhLEEOCMrvLtNR@public.gmane.org>
2014-06-30 15:06       ` Jerome Glisse
2014-06-30 15:06         ` Jerome Glisse
2014-06-30 15:40       ` Joerg Roedel
2014-06-30 16:06         ` Jerome Glisse
2014-06-30 16:06           ` Jerome Glisse
2014-06-30 18:16           ` Joerg Roedel
2014-06-30 18:16             ` Joerg Roedel
2014-06-30 18:35             ` Jerome Glisse
2014-06-30 18:35               ` Jerome Glisse
2014-06-30 18:57               ` Lewycky, Andrew
2014-06-30 18:57                 ` Lewycky, Andrew
2014-07-01  9:41                 ` Joerg Roedel
2014-07-01  9:41                   ` Joerg Roedel
     [not found]               ` <20140630183556.GB3280-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-01  9:15                 ` Joerg Roedel
2014-07-01  9:29                   ` Gabbay, Oded
2014-07-01  9:29                     ` Gabbay, Oded
     [not found]                     ` <019CCE693E457142B37B791721487FD91806DD8B-0nO7ALo/ziwxlywnonMhLEEOCMrvLtNR@public.gmane.org>
2014-07-01 11:00                       ` Joerg Roedel
2014-07-01 19:33                         ` Jerome Glisse
2014-07-01 19:33                           ` Jerome Glisse
     [not found]                           ` <20140701193343.GB3322-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-01 21:06                             ` Joerg Roedel
2014-07-01 21:32                               ` Jerome Glisse
2014-07-01 21:32                                 ` Jerome Glisse
2014-07-03 18:30                                 ` Jerome Glisse
2014-07-03 18:30                                   ` Jerome Glisse
     [not found]                                   ` <20140703183024.GA3306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-03 23:15                                     ` Joerg Roedel
2014-07-04  0:03                                       ` Jerome Glisse
2014-07-04  0:03                                         ` Jerome Glisse
     [not found]                                       ` <20140703231541.GR26537-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-07-06 19:25                                         ` Gabbay, Oded
2014-07-06 19:25                                           ` Gabbay, Oded
2014-07-07 10:11                                           ` joro
2014-07-07 10:11                                             ` joro
2014-07-07 10:36                                             ` Oded Gabbay
2014-07-07 10:36                                               ` Oded Gabbay
2014-07-07 10:43                                             ` Oded Gabbay
2014-07-07 10:43                                               ` Oded Gabbay
     [not found]                                               ` <1404729783.31606.1.camel-OrheeFI7RUaGvNAqNQFwiPZ4XP/Yx64J@public.gmane.org>
2014-07-08  8:00                                                 ` joro-zLv9SwRftAIdnm+yROfE0A
     [not found]                                                   ` <20140708080059.GF1958-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-07-08 17:03                                                     ` Jerome Glisse
2014-07-08 17:03                                                       ` Jerome Glisse
2015-10-11 19:03                                                       ` David Woodhouse
2015-10-11 19:03                                                         ` David Woodhouse
     [not found]                                                         ` <1444590209.92154.116.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-10-12 17:41                                                           ` Jerome Glisse
2015-10-12 17:41                                                             ` Jerome Glisse
2015-10-12 17:41                                                             ` Jerome Glisse
2015-11-20 15:45                                                         ` David Woodhouse
2015-11-20 15:45                                                           ` David Woodhouse
2014-06-30 15:37   ` Joerg Roedel
2014-06-28  2:00 ` [PATCH 2/6] mm: differentiate unmap for vmscan from other unmap Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:58   ` John Hubbard
2014-06-30  3:58     ` John Hubbard
2014-06-30 15:58     ` Jerome Glisse [this message]
2014-06-30 15:58       ` Jerome Glisse
2014-06-28  2:00 ` [PATCH 3/6] mmu_notifier: add event information to address invalidation v2 Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  5:22   ` John Hubbard
2014-06-30  5:22     ` John Hubbard
2014-06-30 15:57     ` Jerome Glisse
2014-06-30 15:57       ` Jerome Glisse
2014-07-01  1:57   ` Linus Torvalds
2014-06-28  2:00 ` [PATCH 4/6] mmu_notifier: pass through vma to invalidate_range and invalidate_page Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:29   ` John Hubbard
2014-06-30  3:29     ` John Hubbard
2014-06-30 16:00     ` Jerome Glisse
2014-06-30 16:00       ` Jerome Glisse
2014-07-01  2:04   ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140630155838.GD1956@gmail.com \
    --to=j.glisse@gmail.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Andrew.Lewycky@amd.com \
    --cc=Oded.Gabbay@amd.com \
    --cc=SCheung@nvidia.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arvindg@nvidia.com \
    --cc=cabuschardt@nvidia.com \
    --cc=dpoole@nvidia.com \
    --cc=hpa@zytor.com \
    --cc=jakumar@nvidia.com \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=jweiner@redhat.com \
    --cc=ldunning@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhairgrove@nvidia.com \
    --cc=peterz@infraread.org \
    --cc=riel@redhat.com \
    --cc=sgutti@nvidia.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.