On Wed, Jul 25, 2012 at 11:57:13AM -0700, Andrew Morton wrote:
> On Wed, 25 Jul 2012 09:35:03 +0200
> Johannes Weiner <han...@cmpxchg.org> wrote:
> 
> > As this is unlikely to reappear in this merge window, the conflict
> > resolution is quite simple.  All that's needed is remove the 3 hunks
> > from my patch that converted a user in Peter's patch to a new API.  I
> > can resend the series if needed, but it's probably easier to just
> > remove the hunks against mm/migrate.c::migrate_misplaced_page():
> > 
> > @@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct 
> > mm_struct *mm, int node)
> >  {
> >     struct page *oldpage = page, *newpage;
> >     struct address_space *mapping = page_mapping(page);
> > -   struct mem_cgroup *mcg;
> > +   struct mem_cgroup *memcg;
> >     unsigned int gfp;
> >     int rc = 0;
> > -   int charge = -ENOMEM;
> >  
> >     VM_BUG_ON(!PageLocked(page));
> >     VM_BUG_ON(page_mapcount(page));
> > @@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct 
> > mm_struct *mm, int node)
> >     if (!trylock_page(newpage))
> >             BUG();          /* new page should be unlocked!!! */
> >  
> > -   // XXX hnaz, is this right?
> > -   charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
> > -   if (charge == -ENOMEM) {
> > -           rc = charge;
> > -           goto out;
> > -   }
> > +   mem_cgroup_prepare_migration(page, newpage, &memcg);
> >  
> >     newpage->index = page->index;
> >     newpage->mapping = page->mapping;
> > @@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct 
> > mm_struct *mm, int node)
> >             page = newpage;
> >     }
> >  
> > +   mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
> >  out:
> > -   if (!charge)
> > -           mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
> > -
> > -       if (oldpage != page)
> > +   if (oldpage != page)
> >                 put_page(oldpage);
> >  
> >     if (rc) {
> 
> Yes, that worked out OK.
> 
> This means that if the above code reappears in linux-next or mainline,
> the current copy of
> mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
> will no longer update it, and I probably won't notice that omission. 

The gfp_t argument was dropped from mem_cgroup_prepare_migration(), so
it'll blow up during compilation with CONFIG_NUMA=y.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to