From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751697AbdINUHh (ORCPT ); Thu, 14 Sep 2017 16:07:37 -0400 Received: from mail-pg0-f45.google.com ([74.125.83.45]:47491 "EHLO mail-pg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751277AbdINUHf (ORCPT ); Thu, 14 Sep 2017 16:07:35 -0400 X-Google-Smtp-Source: ADKCNb56W+Xa6MwCH7qiM/xT7bQOQxjyNYEFgyvnrPsiSusd4xTCgJ3bldLrvNBHRnPWZIbOPKFCrw== Date: Thu, 14 Sep 2017 13:07:32 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko cc: Roman Gushchin , linux-mm@kvack.org, Vladimir Davydov , Johannes Weiner , Tetsuo Handa , Andrew Morton , Tejun Heo , kernel-team@fb.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [v8 0/4] cgroup-aware OOM killer In-Reply-To: <20170914133407.e7gstxssq6j5lo25@dhcp22.suse.cz> Message-ID: References: <20170911131742.16482-1-guro@fb.com> <20170913122914.5gdksbmkolum7ita@dhcp22.suse.cz> <20170914133407.e7gstxssq6j5lo25@dhcp22.suse.cz> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Sep 2017, Michal Hocko wrote: > > It is certainly possible to add oom priorities on top before it is merged, > > but I don't see why it isn't part of the patchset. > > Because the semantic of the priority for non-leaf memcgs is not fully > clear and I would rather have the core of the functionality merged > before this is sorted out. > We can't merge the core of the feature before this is sorted out because then users start to depend on behavior and we must be backwards compatible. We need a full patchset that introduces the new selection heuristic and a way for userspace to control it to either bias or prefer one cgroup over another. The kill-all mechanism is a more orthogonal feature for the cgroup-aware oom killer than oom priorities. I have a usecase for both the cgroup-aware oom killer and its oom priorities from previous versions of this patchset, I assume that Roman does as well, and would like to see it merged bacause there are real-world usecases for it rather than hypothetical usecases that would want to do something different. > > We need it before its > > merged to avoid users playing with /proc/pid/oom_score_adj to prevent any > > killing in the most preferable memcg when they could have simply changed > > the oom priority. > > I am sorry but I do not really understand your concern. Are you > suggesting that users would start oom disable all tasks in a memcg to > give it a higher priority? Even if that was the case why should such an > abuse be a blocker for generic memcg aware oom killer being merged? If users do not have any way to control victim selection because of a shortcoming in the kernel implementation, they will be required to oom disable processes and let that be inherited by children they fork in the memcg hierarchy to protect cgroups that they do not want to be oom killed, regardless of their size. They simply are left with no other alternative if they want to use the cgroup-aware oom killer and/or the kill-all mechanism.