Messages in this thread | | | Date | Tue, 26 Jun 2012 12:11:11 +0900 | From | Kamezawa Hiroyuki <> | Subject | Re: [patch] mm, thp: abort compaction if migration page cannot be charged to memcg |
| |
(2012/06/26 9:32), David Rientjes wrote: > On Mon, 25 Jun 2012, Rik van Riel wrote: > >> The patch makes sense, however I wonder if it would make >> more sense in the long run to allow migrate/compaction to >> temporarily exceed the memcg memory limit for a cgroup, >> because the original page will get freed again soon anyway. >> >> That has the potential to improve compaction success, and >> reduce compaction related CPU use. >> > > Yeah, Kame brought up the same point with a sample patch by allowing the > temporary charge for the new page. It would certainly solve this problem > in a way that we don't have to even touch compaction, it's disappointing > that we have to charge memory to do a page migration. I'm not so sure > about the approach of temporarily allowing the excess charge, however, > since it would scale with the number of cpus doing compaction or > migration, which could end up with PAGE_SIZE * nr_cpu_ids. >
I don't think it's problem. Even if there are 4096 cpus, it's only 16MB on that system, which tends to have terabytes of memory. (We already have 32pages of per-cpu-cache....)
I'd like to post that patch with updating to mmotm.
> I haven't looked at it (yet), but I'm hoping that there's a way to avoid > charging the temporary page at all until after move_to_new_page() > succeeds, i.e. find a way to uncharge page before charging newpage.
Hmm...this code has been verrry racy and we did many mis-accounting. So, I'd like to start from a safe way.
THanks, -Kame
| |