Messages in this thread |  | | | Date | Fri, 28 Jan 2011 17:24:38 +0900 | | From | KAMEZAWA Hiroyuki <> | | Subject | Re: [BUGFIX][PATCH 1/4] memcg: fix limit estimation at reclaim for hugepage |
| |
On Fri, 28 Jan 2011 17:04:16 +0900 Minchan Kim <minchan.kim@gmail.com> wrote:
> Hi Kame, > > On Fri, Jan 28, 2011 at 1:58 PM, KAMEZAWA Hiroyuki > <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > How about this ? > > == > > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > > > > Current memory cgroup's code tends to assume page_size == PAGE_SIZE > > and arrangement for THP is not enough yet. > > > > This is one of fixes for supporing THP. This adds > > mem_cgroup_check_margin() and checks whether there are required amount of > > free resource after memory reclaim. By this, THP page allocation > > can know whether it really succeeded or not and avoid infinite-loop > > and hangup. > > > > Total fixes for do_charge()/reclaim memory will follow this patch. > > If this patch is only related to THP, I think patch order isn't good. > Before applying [2/4], huge page allocation will retry without > reclaiming and loop forever by below part. > > @@ -1854,9 +1858,6 @@ static int __mem_cgroup_do_charge(struct > } else > mem_over_limit = mem_cgroup_from_res_counter(fail_res, res); > > - if (csize > PAGE_SIZE) /* change csize and retry */ > - return CHARGE_RETRY; > - > if (!(gfp_mask & __GFP_WAIT)) > return CHARGE_WOULDBLOCK; > > Am I missing something? >
You're right. But - This patch oder doesn't affect bi-sect of the bug. because 2 bugs seems to be the same. - This patch implements a leaf function for the real fix.
Then, I think patch order is not problem here.
Thank you for pointing out.
Thanks, -Kame
|  |