From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933180Ab0FCG3J (ORCPT ); Thu, 3 Jun 2010 02:29:09 -0400 Received: from smtp-out.google.com ([216.239.44.51]:31603 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932880Ab0FCG3G (ORCPT ); Thu, 3 Jun 2010 02:29:06 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=mbGFT0GVuQFXZNeIsmU00dRRooGIFOql6bRKjDRyKE7w2xgipD5Bxec497sXtdoFa MhEuHlit5VRG97wK/rYuQ== Date: Wed, 2 Jun 2010 23:29:00 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: KOSAKI Motohiro cc: Oleg Nesterov , LKML , linux-mm , Andrew Morton , KAMEZAWA Hiroyuki , Nick Piggin Subject: Re: [PATCH] oom: remove PF_EXITING check completely In-Reply-To: <20100603120814.7242.A69D9226@jp.fujitsu.com> Message-ID: References: <20100602155455.GB9622@redhat.com> <20100603120814.7242.A69D9226@jp.fujitsu.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jun 2010, KOSAKI Motohiro wrote: > > On Wed, 2 Jun 2010, Oleg Nesterov wrote: > > > > > > Today, I've thought to make some bandaid patches for this issue. but > > > > yes, I've reached the same conclusion. > > > > > > > > If we think multithread and core dump situation, all fixes are just > > > > bandaid. We can't remove deadlock chance completely. > > > > > > > > The deadlock is certenaly worst result, then, minor PF_EXITING optimization > > > > doesn't have so much worth. > > > > > > Agreed! I was always wondering if it really helps in practice. > > > > > > > Nack, this certainly does help in practice, it prevents needlessly killing > > additional tasks when one is exiting and may free memory. It's much > > better to defer killing something temporarily if an eligible task (i.e. > > one that has a high probability of memory allocations on current's nodes > > or contributing to its memcg) is exiting. > > > > We depend on this check specifically for our use of cpusets, so please > > don't remove it. > > Your claim violate our development process. Oleg pointed this check > doesn't only work well, but also can makes deadlock. So, We certinally > need anything fix. then, I'll remove this check completely at 2.6.35 > timeframe. > Show me your deadlock. I want to see it. In practice. We've been using this check specifically for three years and it prevents needlessly killing additional tasks when one is already exiting and will free its memory. That's a crucial aspect of using cpusets that run out of memory constantly. Unless you actually have real world experience with using the oom killer to affect a memory containment strategy, I don't buy into your overly exaggerated claims that these are all bugfixes and these races that you have no practical evidence to support actually even matter but speculate based on pure code inspection are important. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with ESMTP id C6ED46B01D5 for ; Thu, 3 Jun 2010 02:29:08 -0400 (EDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o536T5wf027080 for ; Wed, 2 Jun 2010 23:29:06 -0700 Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by hpaq3.eem.corp.google.com with ESMTP id o536T3ga030953 for ; Wed, 2 Jun 2010 23:29:04 -0700 Received: by pzk6 with SMTP id 6so1533556pzk.1 for ; Wed, 02 Jun 2010 23:29:03 -0700 (PDT) Date: Wed, 2 Jun 2010 23:29:00 -0700 (PDT) From: David Rientjes Subject: Re: [PATCH] oom: remove PF_EXITING check completely In-Reply-To: <20100603120814.7242.A69D9226@jp.fujitsu.com> Message-ID: References: <20100602155455.GB9622@redhat.com> <20100603120814.7242.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: KOSAKI Motohiro Cc: Oleg Nesterov , LKML , linux-mm , Andrew Morton , KAMEZAWA Hiroyuki , Nick Piggin List-ID: On Thu, 3 Jun 2010, KOSAKI Motohiro wrote: > > On Wed, 2 Jun 2010, Oleg Nesterov wrote: > > > > > > Today, I've thought to make some bandaid patches for this issue. but > > > > yes, I've reached the same conclusion. > > > > > > > > If we think multithread and core dump situation, all fixes are just > > > > bandaid. We can't remove deadlock chance completely. > > > > > > > > The deadlock is certenaly worst result, then, minor PF_EXITING optimization > > > > doesn't have so much worth. > > > > > > Agreed! I was always wondering if it really helps in practice. > > > > > > > Nack, this certainly does help in practice, it prevents needlessly killing > > additional tasks when one is exiting and may free memory. It's much > > better to defer killing something temporarily if an eligible task (i.e. > > one that has a high probability of memory allocations on current's nodes > > or contributing to its memcg) is exiting. > > > > We depend on this check specifically for our use of cpusets, so please > > don't remove it. > > Your claim violate our development process. Oleg pointed this check > doesn't only work well, but also can makes deadlock. So, We certinally > need anything fix. then, I'll remove this check completely at 2.6.35 > timeframe. > Show me your deadlock. I want to see it. In practice. We've been using this check specifically for three years and it prevents needlessly killing additional tasks when one is already exiting and will free its memory. That's a crucial aspect of using cpusets that run out of memory constantly. Unless you actually have real world experience with using the oom killer to affect a memory containment strategy, I don't buy into your overly exaggerated claims that these are all bugfixes and these races that you have no practical evidence to support actually even matter but speculate based on pure code inspection are important. -- 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