From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966576AbbLQAum (ORCPT ); Wed, 16 Dec 2015 19:50:42 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:40645 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966041AbbLQAuh (ORCPT ); Wed, 16 Dec 2015 19:50:37 -0500 Date: Wed, 16 Dec 2015 16:50:35 -0800 From: Andrew Morton To: Michal Hocko Cc: Mel Gorman , Tetsuo Handa , David Rientjes , Linus Torvalds , Oleg Nesterov , Hugh Dickins , Andrea Argangeli , Rik van Riel , , LKML , Michal Hocko Subject: Re: [PATCH 1/2] mm, oom: introduce oom reaper Message-Id: <20151216165035.38a4d9b84600d6348a3cf4bf@linux-foundation.org> In-Reply-To: <1450204575-13052-1-git-send-email-mhocko@kernel.org> References: <1450204575-13052-1-git-send-email-mhocko@kernel.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Dec 2015 19:36:15 +0100 Michal Hocko wrote: > From: Michal Hocko > > This is based on the idea from Mel Gorman discussed during LSFMM 2015 and > independently brought up by Oleg Nesterov. > > The OOM killer currently allows to kill only a single task in a good > hope that the task will terminate in a reasonable time and frees up its > memory. Such a task (oom victim) will get an access to memory reserves > via mark_oom_victim to allow a forward progress should there be a need > for additional memory during exit path. > > ... > > +static void oom_reap_vmas(struct mm_struct *mm) > +{ > + int attempts = 0; > + > + while (attempts++ < 10 && !__oom_reap_vmas(mm)) > + schedule_timeout(HZ/10); schedule_timeout() in state TASK_RUNNING doesn't do anything. Use msleep() or msleep_interruptible(). I can't decide which is more appropriate - it only affects the load average display. Which prompts the obvious question: as the no-operativeness of this call wasn't noticed in testing, why do we have it there... I guess it means that the __oom_reap_vmas() success rate is nice and high ;) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by kanga.kvack.org (Postfix) with ESMTP id 238AD6B0038 for ; Wed, 16 Dec 2015 19:50:37 -0500 (EST) Received: by mail-pf0-f177.google.com with SMTP id n128so2096150pfn.0 for ; Wed, 16 Dec 2015 16:50:37 -0800 (PST) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org. [140.211.169.12]) by mx.google.com with ESMTPS id w74si8438931pfi.130.2015.12.16.16.50.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Dec 2015 16:50:36 -0800 (PST) Date: Wed, 16 Dec 2015 16:50:35 -0800 From: Andrew Morton Subject: Re: [PATCH 1/2] mm, oom: introduce oom reaper Message-Id: <20151216165035.38a4d9b84600d6348a3cf4bf@linux-foundation.org> In-Reply-To: <1450204575-13052-1-git-send-email-mhocko@kernel.org> References: <1450204575-13052-1-git-send-email-mhocko@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Mel Gorman , Tetsuo Handa , David Rientjes , Linus Torvalds , Oleg Nesterov , Hugh Dickins , Andrea Argangeli , Rik van Riel , linux-mm@kvack.org, LKML , Michal Hocko On Tue, 15 Dec 2015 19:36:15 +0100 Michal Hocko wrote: > From: Michal Hocko > > This is based on the idea from Mel Gorman discussed during LSFMM 2015 and > independently brought up by Oleg Nesterov. > > The OOM killer currently allows to kill only a single task in a good > hope that the task will terminate in a reasonable time and frees up its > memory. Such a task (oom victim) will get an access to memory reserves > via mark_oom_victim to allow a forward progress should there be a need > for additional memory during exit path. > > ... > > +static void oom_reap_vmas(struct mm_struct *mm) > +{ > + int attempts = 0; > + > + while (attempts++ < 10 && !__oom_reap_vmas(mm)) > + schedule_timeout(HZ/10); schedule_timeout() in state TASK_RUNNING doesn't do anything. Use msleep() or msleep_interruptible(). I can't decide which is more appropriate - it only affects the load average display. Which prompts the obvious question: as the no-operativeness of this call wasn't noticed in testing, why do we have it there... I guess it means that the __oom_reap_vmas() success rate is nice and high ;) -- 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