From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752383Ab3IROdL (ORCPT ); Wed, 18 Sep 2013 10:33:11 -0400 Received: from gmmr8.centrum.cz ([46.255.227.254]:47315 "EHLO gmmr8.centrum.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751900Ab3IROdJ (ORCPT ); Wed, 18 Sep 2013 10:33:09 -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 16:33:06 +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: <20130916140607.GC3674@dhcp22.suse.cz>, <20130916161316.5113F6E7@pobox.sk>, <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> In-Reply-To: <20130918142400.GA3421@dhcp22.suse.cz> X-Mailer: Centrum Email 5.3 X-Priority: 3 X-Original-From: azurit@pobox.sk MIME-Version: 1.0 Message-Id: <20130918163306.3620C973@pobox.sk> X-Maser: Georgo 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 > 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: http://watchdog.sk/lkml/htop3.jpg (here you can see actual memory usage) http://watchdog.sk/lkml/server01.jpg If i was really having global OOM (which i'm not for 101%) where that i/o comes from? I have no swap. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "azurIt" Subject: =?utf-8?q?Re=3A_=5Bpatch_0=2F7=5D_improve_memcg_oom_killer_robustness_v2?= Date: Wed, 18 Sep 2013 16:33:06 +0200 Message-ID: <20130918163306.3620C973@pobox.sk> References: <20130916140607.GC3674@dhcp22.suse.cz>, <20130916161316.5113F6E7@pobox.sk>, <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20130918142400.GA3421@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org To: =?utf-8?q?Michal_Hocko?= 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?= , linux-mm@kvack.org, cgroups@vger.kernel.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org List-Id: linux-arch.vger.kernel.org > CC: "Johannes Weiner" , "Andrew Morton" , "David Rientjes" , "KAMEZAWA Hiroy= uki" , "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: >>=20 >> First (doesn't look very helpfull): >> [] 0xffffffffffffffff > >No it is not. >=20 >> 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: http://watchdog.sk/lkml/htop3.jpg (here you can see actual memory usage) http://watchdog.sk/lkml/server01.jpg If i was really having global OOM (which i'm not for 101%) where that i/o= comes from? I have no swap. -- 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