Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755213Ab1EXI5K (ORCPT ); Tue, 24 May 2011 04:57:10 -0400 Received: from mail-qy0-f174.google.com ([209.85.216.174]:57350 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754582Ab1EXI5I convert rfc822-to-8bit (ORCPT ); Tue, 24 May 2011 04:57:08 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fJuZsdZGh7hjNkdexyPqotarlpjUTrhFj6dD/EcS3E7A5NwwjZmNa62+HlGSJlWOY4 VJNb60KGnDWxnQM5zrMiFrQVjTZl7kGLpP11vR1KWi8ZFc5ywkUO8eZtFPN4Vuaa1bI+ s2Sv0LB00DlvRCgfJHz5Q/azIXQTlCmQrR3Uw= MIME-Version: 1.0 In-Reply-To: <4DDB6F48.1010809@jp.fujitsu.com> References: <4DCDA347.9080207@cray.com> <4DD2991B.5040707@cray.com> <20110520164924.GB2386@barrios-desktop> <4DDB3A1E.6090206@jp.fujitsu.com> <4DDB6F48.1010809@jp.fujitsu.com> Date: Tue, 24 May 2011 17:57:07 +0900 Message-ID: Subject: Re: Unending loop in __alloc_pages_slowpath following OOM-kill; rfc: patch. From: Minchan Kim To: KOSAKI Motohiro Cc: abarry@cray.com, akpm@linux-foundation.org, linux-mm@kvack.org, mgorman@suse.de, riel@redhat.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, fengguang.wu@intel.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2358 Lines: 78 On Tue, May 24, 2011 at 5:41 PM, KOSAKI Motohiro wrote: >>> I'm sorry I missed this thread long time. >> >> No problem. It would be better than not review. > > thx. > > >>> In this case, I think we should call drain_all_pages(). then following >>> patch is better. >> >> Strictly speaking, this problem isn't related to drain_all_pages. >> This problem caused by lru empty but I admit it could work well if >> your patch applied. >> So yours could help, too. >> >>> However I also think your patch is valuable. because while the task is >>> sleeping in wait_iff_congested(), an another task may free some pages. >>> thus, rebalance path should try to get free pages. iow, you makes sense. >> >> Yes. >> Off-topic. >> I would like to move cond_resched below get_page_from_freelist in >> __alloc_pages_direct_reclaim. Otherwise, it is likely we can be stolen >> pages to other processes. >> One more benefit is that if it's apparently OOM path(ie, >> did_some_progress = 0), we can reduce OOM kill latency due to remove >> unnecessary cond_resched. > > I agree. Can you please mind to send a patch? I had but at that time, Andrew had a concern. I will resend it when I have a time. Let's discuss, again. > > >>> So, I'd like to propose to merge both your and my patch. >> >> Recently, there was discussion on drain_all_pages with Wu. >> He saw much overhead in 8-core system, AFAIR. >> I Cced Wu. >> >> How about checking per-cpu before calling drain_all_pages() than >> unconditional calling? >> if (per_cpu_ptr(zone->pageset, smp_processor_id()) >>     drain_all_pages(); >> >> Of course, It can miss other CPU free pages. But above routine assume >> local cpu direct reclaim is successful but it failed by per-cpu. So I >> think it works. > > Can you please tell me previous discussion url or mail subject? > I mean, if it is costly and performance degression risk, we don't have to > take my idea. Yes. You could see it by https://lkml.org/lkml/2011/4/30/81. > > Thanks. > > >> >> Thanks for good suggestion and Reviewed-by, KOSAKI. > > > -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/