Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753406Ab3IRSCo (ORCPT ); Wed, 18 Sep 2013 14:02:44 -0400 Received: from gmmr5.centrum.cz ([46.255.225.250]:46357 "EHLO gmmr5.centrum.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751732Ab3IRSCm (ORCPT ); Wed, 18 Sep 2013 14:02:42 -0400 To: =?utf-8?q?Michal_Hocko?= Subject: =?utf-8?q?Re=3A_=5Bpatch_0=2F7=5D_improve_memcg_oom_killer_robustness_v2?= Date: Wed, 18 Sep 2013 20:02:39 +0200 From: "azurIt" Cc: =?utf-8?q?Johannes_Weiner?= , =?utf-8?q?Andrew_Morton?= , =?utf-8?q?David_Rientjes?= , =?utf-8?q?KAMEZAWA_Hiroyuki?= , =?utf-8?q?KOSAKI_Motohiro?= , , , , , References: <20130916145744.GE3674@dhcp22.suse.cz>, <20130916170543.77F1ECB4@pobox.sk>, <20130916152548.GF3674@dhcp22.suse.cz>, <20130916225246.A633145B@pobox.sk>, <20130917000244.GD3278@cmpxchg.org>, <20130917131535.94E0A843@pobox.sk>, <20130917141013.GA30838@dhcp22.suse.cz>, <20130918160304.6EDF2729@pobox.sk>, <20130918142400.GA3421@dhcp22.suse.cz>, <20130918163306.3620C973@pobox.sk> <20130918144245.GC3421@dhcp22.suse.cz> In-Reply-To: <20130918144245.GC3421@dhcp22.suse.cz> X-Mailer: Centrum Email 5.3 X-Priority: 3 X-Original-From: azurit@pobox.sk MIME-Version: 1.0 Message-Id: <20130918200239.DDA96791@pobox.sk> X-Maser: brud 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: 3009 Lines: 60 > CC: "Johannes Weiner" , "Andrew Morton" , "David Rientjes" , "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" , linux-mm@kvack.org, cgroups@vger.kernel.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org >On Wed 18-09-13 16:33:06, azurIt wrote: >> > CC: "Johannes Weiner" , "Andrew Morton" , "David Rientjes" , "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" , linux-mm@kvack.org, cgroups@vger.kernel.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org >> >On Wed 18-09-13 16:03:04, azurIt wrote: >> >[..] >> >> I was finally able to get stack of problematic process :) I saved it >> >> two times from the same process, as Michal suggested (i wasn't able to >> >> take more). Here it is: >> >> >> >> First (doesn't look very helpfull): >> >> [] 0xffffffffffffffff >> > >> >No it is not. >> > >> >> Second: >> >> [] shrink_zone+0x481/0x650 >> >> [] do_try_to_free_pages+0xde/0x550 >> >> [] try_to_free_pages+0x9b/0x120 >> >> [] free_more_memory+0x5d/0x60 >> >> [] __getblk+0x14d/0x2c0 >> >> [] __bread+0x13/0xc0 >> >> [] ext3_get_branch+0x98/0x140 >> >> [] ext3_get_blocks_handle+0xd7/0xdc0 >> >> [] ext3_get_block+0xc4/0x120 >> >> [] do_mpage_readpage+0x38a/0x690 >> >> [] mpage_readpages+0xfb/0x160 >> >> [] ext3_readpages+0x1d/0x20 >> >> [] __do_page_cache_readahead+0x1c5/0x270 >> >> [] ra_submit+0x21/0x30 >> >> [] filemap_fault+0x380/0x4f0 >> >> [] __do_fault+0x78/0x5a0 >> >> [] handle_pte_fault+0x84/0x940 >> >> [] handle_mm_fault+0x16a/0x320 >> >> [] do_page_fault+0x13b/0x490 >> >> [] page_fault+0x1f/0x30 >> >> [] 0xffffffffffffffff >> > >> >This is the direct reclaim path. You are simply running out of memory >> >globaly. There is no memcg specific code in that trace. >> >> >> No, i'm not. Here is htop and server graphs from this case: > >Bahh, right you are. I didn't look at the trace carefully. It is >free_more_memory which calls the direct reclaim shrinking. > >Sorry about the confusion Happens again and this time i got 5x this: [] 0xffffffffffffffff :( it's probably looping very fast so i need to have some luck azur -- 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/