From: Jerome Glisse <jglisse@redhat.com>
To: Balbir Singh <bsingharora@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
John Hubbard <jhubbard@nvidia.com>,
David Nellans <dnellans@nvidia.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
cgroups@vger.kernel.org
Subject: Re: [HMM-CDM 3/5] mm/memcontrol: allow to uncharge page without using page->lru field
Date: Thu, 15 Jun 2017 11:35:34 -0400 [thread overview]
Message-ID: <20170615153533.GA3837@redhat.com> (raw)
In-Reply-To: <20170615133128.2fe2c33f@firefly.ozlabs.ibm.com>
On Thu, Jun 15, 2017 at 01:31:28PM +1000, Balbir Singh wrote:
> On Wed, 14 Jun 2017 16:11:42 -0400
> Jerome Glisse <jglisse@redhat.com> wrote:
>
> > HMM pages (private or public device pages) are ZONE_DEVICE page and
> > thus you can not use page->lru fields of those pages. This patch
> > re-arrange the uncharge to allow single page to be uncharge without
> > modifying the lru field of the struct page.
> >
> > There is no change to memcontrol logic, it is the same as it was
> > before this patch.
> >
> > Signed-off-by: Jerome Glisse <jglisse@redhat.com>
> > Cc: Johannes Weiner <hannes@cmpxchg.org>
> > Cc: Michal Hocko <mhocko@kernel.org>
> > Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
> > Cc: cgroups@vger.kernel.org
> > ---
> > mm/memcontrol.c | 168 +++++++++++++++++++++++++++++++-------------------------
> > 1 file changed, 92 insertions(+), 76 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index e3fe4d0..b93f5fe 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -5509,48 +5509,102 @@ void mem_cgroup_cancel_charge(struct page *page, struct mem_cgroup *memcg,
> > cancel_charge(memcg, nr_pages);
> > }
> >
> > -static void uncharge_batch(struct mem_cgroup *memcg, unsigned long pgpgout,
> > - unsigned long nr_anon, unsigned long nr_file,
> > - unsigned long nr_kmem, unsigned long nr_huge,
> > - unsigned long nr_shmem, struct page *dummy_page)
> > +struct uncharge_gather {
> > + struct mem_cgroup *memcg;
> > + unsigned long pgpgout;
> > + unsigned long nr_anon;
> > + unsigned long nr_file;
> > + unsigned long nr_kmem;
> > + unsigned long nr_huge;
> > + unsigned long nr_shmem;
> > + struct page *dummy_page;
> > +};
> > +
> > +static inline void uncharge_gather_clear(struct uncharge_gather *ug)
> > {
> > - unsigned long nr_pages = nr_anon + nr_file + nr_kmem;
> > + memset(ug, 0, sizeof(*ug));
> > +}
> > +
> > +static void uncharge_batch(const struct uncharge_gather *ug)
> > +{
>
> Can we pass page as an argument so that we can do check events on the page?
Well it is what dummy page is for, i wanted to keep code as close
to existing to make it easier for people to see that there was no
logic change with that patch.
[...]
> > +static void uncharge_page(struct page *page, struct uncharge_gather *ug)
> > +{
> > + VM_BUG_ON_PAGE(PageLRU(page), page);
> > + VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(page), page);
> > +
> > + if (!page->mem_cgroup)
> > + return;
> > +
> > + /*
> > + * Nobody should be changing or seriously looking at
> > + * page->mem_cgroup at this point, we have fully
> > + * exclusive access to the page.
> > + */
> > +
> > + if (ug->memcg != page->mem_cgroup) {
> > + if (ug->memcg) {
> > + uncharge_batch(ug);
>
> What is ug->dummy_page set to at this point? ug->dummy_page is assigned below
So at begining ug->memcg is NULL and so is ug->dummy_page, after first
call to uncharge_page() if ug->memcg isn't NULL then ug->dummy_page
points to a valid page. So uncharge_batch() can never be call with
dummy_page == NULL same as before this patch.
[...]
> > static void uncharge_list(struct list_head *page_list)
> > {
> > - struct mem_cgroup *memcg = NULL;
> > - unsigned long nr_shmem = 0;
> > - unsigned long nr_anon = 0;
> > - unsigned long nr_file = 0;
> > - unsigned long nr_huge = 0;
> > - unsigned long nr_kmem = 0;
> > - unsigned long pgpgout = 0;
> > + struct uncharge_gather ug;
> > struct list_head *next;
> > - struct page *page;
> > +
> > + uncharge_gather_clear(&ug);
> >
> > /*
> > * Note that the list can be a single page->lru; hence the
> > @@ -5558,57 +5612,16 @@ static void uncharge_list(struct list_head *page_list)
> > */
> > next = page_list->next;
> > do {
> > + struct page *page;
> > +
>
> Nit pick
>
> VM_WARN_ON(is_zone_device_page(page));
Yeah probably good thing to add. I will add it as part of the
other memcontrol patch as i want to keep this one about moving
stuff around with no logic change.
Thanks for reviewing
Jerome
--
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>
next prev parent reply other threads:[~2017-06-15 15:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 20:11 [HMM-CDM 0/5] Cache coherent device memory (CDM) with HMM Jérôme Glisse
2017-06-14 20:11 ` [HMM-CDM 1/5] mm/device-public-memory: device memory cache coherent with CPU Jérôme Glisse
2017-06-14 20:11 ` [HMM-CDM 2/5] mm/hmm: add new helper to hotplug CDM memory region Jérôme Glisse
2017-06-15 4:28 ` Balbir Singh
2017-06-14 20:11 ` [HMM-CDM 3/5] mm/memcontrol: allow to uncharge page without using page->lru field Jérôme Glisse
2017-06-15 3:31 ` Balbir Singh
2017-06-15 15:35 ` Jerome Glisse [this message]
2017-06-14 20:11 ` [HMM-CDM 4/5] mm/memcontrol: support MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_PUBLIC Jérôme Glisse
2017-06-15 1:41 ` Balbir Singh
2017-06-15 2:04 ` Jerome Glisse
2017-06-15 3:10 ` Balbir Singh
2017-06-14 20:11 ` [HMM-CDM 5/5] mm/hmm: simplify kconfig and enable HMM and DEVICE_PUBLIC for ppc64 Jérôme Glisse
2017-06-14 23:10 ` John Hubbard
2017-06-15 2:09 ` Jerome Glisse
2017-06-15 3:15 ` John Hubbard
2017-06-15 1:46 ` Balbir Singh
2017-06-15 2:07 ` Jerome Glisse
2017-06-15 2:59 ` Balbir Singh
2017-06-14 21:20 ` [HMM-CDM 0/5] Cache coherent device memory (CDM) with HMM Dave Hansen
2017-06-14 21:38 ` Jerome Glisse
2017-06-14 21:58 ` Dave Hansen
2017-06-14 22:07 ` Benjamin Herrenschmidt
2017-06-14 23:40 ` Balbir Singh
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=20170615153533.GA3837@redhat.com \
--to=jglisse@redhat.com \
--cc=bsingharora@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=dnellans@nvidia.com \
--cc=hannes@cmpxchg.org \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vdavydov.dev@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).