On Fri, Jan 28, 2011 at 5:24 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > On Fri, 28 Jan 2011 17:04:16 +0900 > Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > >> Hi Kame, >> >> On Fri, Jan 28, 2011 at 1:58 PM, KAMEZAWA Hiroyuki >> <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: >> > How about this ? >> > == >> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> >> > >> > 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. Okay. I understand Hannes and your opinion. In my opinion, my suggestion can enhance the patch readability in this series as just only my viewpoint. :) Anyway, I don't mind it. Reviewed-by: Minchan Kim <minchan.kim@xxxxxxxxx> Thanks!! > > Thanks, > -Kame > > > > > -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href