Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751721AbaLQLrz (ORCPT ); Wed, 17 Dec 2014 06:47:55 -0500 Received: from smtp.codeaurora.org ([198.145.11.231]:46495 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751047AbaLQLrx (ORCPT ); Wed, 17 Dec 2014 06:47:53 -0500 Message-ID: <54916D63.7060701@codeaurora.org> Date: Wed, 17 Dec 2014 17:17:47 +0530 From: Chintan Pandya User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: David Rientjes CC: Michal Hocko , hannes@cmpxchg.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] memcg: Provide knob for force OOM into the memcg References: <1418736335-30915-1-git-send-email-cpandya@codeaurora.org> <20141216133935.GK22914@dhcp22.suse.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/17/2014 04:03 AM, David Rientjes wrote: > On Tue, 16 Dec 2014, Michal Hocko wrote: > >>> We may want to use memcg to limit the total memory >>> footprint of all the processes within the one group. >>> This may lead to a situation where any arbitrary >>> process cannot get migrated to that one memcg >>> because its limits will be breached. Or, process can >>> get migrated but even being most recently used >>> process, it can get killed by in-cgroup OOM. To >>> avoid such scenarios, provide a convenient knob >>> by which we can forcefully trigger OOM and make >>> a room for upcoming process. >>> >>> To trigger force OOM, >>> $ echo 1> //memory.force_oom >> >> What would prevent another task deplete that memory shortly after you >> triggered OOM and end up in the same situation? E.g. while the moving >> task is migrating its charges to the new group... Idea was to trigger an OOM until we can migrate any particular process onto desired cgroup. >> >> Why cannot you simply disable OOM killer in that memcg and handle it >> from userspace properly? Well, this can be done it seems. Let me explore around this. Thanks for this suggestion. > It seems to be proposed as a shortcut so that the kernel will determine > the best process to kill. That information is available to userspace so > it should be able to just SIGKILL the desired process (either in the > destination memcg or in the source memcg to allow deletion), so this > functionality isn't needed in the kernel. Yes, this can be seen as a shortcut because we are off-loading some task-selection to be killed by OOM on kernel rather than userspace decides by itself. -- Chintan Pandya QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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/