From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx164.postini.com [74.125.245.164]) by kanga.kvack.org (Postfix) with SMTP id CDEF26B0031 for ; Wed, 31 Jul 2013 22:45:23 -0400 (EDT) Received: by mail-ye0-f174.google.com with SMTP id q9so576291yen.33 for ; Wed, 31 Jul 2013 19:45:22 -0700 (PDT) Message-ID: <51F9CBC0.2020006@gmail.com> Date: Wed, 31 Jul 2013 22:45:20 -0400 From: KOSAKI Motohiro MIME-Version: 1.0 Subject: Re: Possible deadloop in direct reclaim? References: <89813612683626448B837EE5A0B6A7CB3B62F8F272@SC-VEXCH4.marvell.com> <000001400d38469d-a121fb96-4483-483a-9d3e-fc552e413892-000000@email.amazonses.com> <89813612683626448B837EE5A0B6A7CB3B62F8F5C3@SC-VEXCH4.marvell.com> <89813612683626448B837EE5A0B6A7CB3B62F8FE33@SC-VEXCH4.marvell.com> <51F69BD7.2060407@gmail.com> <89813612683626448B837EE5A0B6A7CB3B630BDF99@SC-VEXCH4.marvell.com> In-Reply-To: <89813612683626448B837EE5A0B6A7CB3B630BDF99@SC-VEXCH4.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Lisa Du Cc: KOSAKI Motohiro , Christoph Lameter , "linux-mm@kvack.org" , Mel Gorman , Bob Liu (7/31/13 10:24 PM), Lisa Du wrote: > Dear Kosaki > Would you please help to check my comment as below: >> (7/25/13 9:11 PM), Lisa Du wrote: >>> Dear KOSAKI >>> In my test, I didn't set compaction. Maybe compaction is helpful to >> avoid this issue. I can have try later. >>> In my mind CONFIG_COMPACTION is an optional configuration >> right? >> >> Right. But if you don't set it, application must NOT use >1 order allocations. >> It doesn't work and it is expected >> result. >> That's your application mistake. > Dear Kosaki, I have two questions on your explanation: > a) you said if don't set CONFIG_COMPATION, application must NOT use >1 order allocations, is there any documentation for this theory? Sorry I don't understand what "this" mean. I mean, Even though you use desktop or server machine, no compaction kernel easily makes no order-2 situations. Then, our in-kernel subsystems don't use order-2 allocations as far as possible. > b) My order-2 allocation not comes from application, but from do_fork which is in kernel space, in my mind when a parent process forks a child process, it need to allocate a order-2 memory, if a) is right, then CONFIG_COMPATION should be a MUST configuration for linux kernel but not optional? ??? fork alloc order-1 memory for stack. Where and why alloc order-2? If it is arch specific code, please contact arch maintainer. >> >>> If we don't use, and met such an issue, how should we deal with >> such infinite loop? >>> >>> I made a change in all_reclaimable() function, passed overnight tests, >> please help review, thanks in advance! >>> @@ -2353,7 +2353,9 @@ static bool all_unreclaimable(struct zonelist >> *zonelist, >>> continue; >>> if (!cpuset_zone_allowed_hardwall(zone, >> GFP_KERNEL)) >>> continue; >>> - if (!zone->all_unreclaimable) >>> + if (zone->all_unreclaimable) >>> + continue; >>> + if (zone_reclaimable(zone)) >>> return false; >> >> Please tell me why you chaned here. > The original check is once found zone->all_unreclaimable is false, it will return false, then >it will set did_some_progress non-zero. Then another loop of direct_reclaimed performed. > But I think zone->all_unreclaimable is not always reliable such as in my case, kswapd go to > sleep and no one will change this flag. We should also check zone_reclaimalbe(zone) if > zone->all_unreclaimalbe = 0 to double confirm if a zone is reclaimable; This change also > avoid the issue you described in below commit: Please read more older code. Your pointed code is temporary change and I changed back for fixing bugs. If you look at the status in middle direct reclaim, we can't avoid race condition from multi direct reclaim issues. Moreover, if kswapd doesn't awaken, it is a problem. This is a reason why current code behave as you described. I agree we should fix your issue as far as possible. But I can't agree your analysis. -- 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: email@kvack.org