Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751997AbdI0HnX (ORCPT ); Wed, 27 Sep 2017 03:43:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:33465 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751983AbdI0HnV (ORCPT ); Wed, 27 Sep 2017 03:43:21 -0400 Date: Wed, 27 Sep 2017 09:43:19 +0200 From: Michal Hocko To: Tim Hockin Cc: Johannes Weiner , Roman Gushchin , Tejun Heo , kernel-team@fb.com, David Rientjes , linux-mm@kvack.org, Vladimir Davydov , Tetsuo Handa , Andrew Morton , Cgroups , linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org" Subject: Re: [v8 0/4] cgroup-aware OOM killer Message-ID: <20170927074319.o3k26kja43rfqmvb@dhcp22.suse.cz> References: <20170925122400.4e7jh5zmuzvbggpe@dhcp22.suse.cz> <20170925170004.GA22704@cmpxchg.org> <20170925181533.GA15918@castle> <20170925202442.lmcmvqwy2jj2tr5h@dhcp22.suse.cz> <20170926105925.GA23139@castle.dhcp.TheFacebook.com> <20170926112134.r5eunanjy7ogjg5n@dhcp22.suse.cz> <20170926121300.GB23139@castle.dhcp.TheFacebook.com> <20170926133040.uupv3ibkt3jtbotf@dhcp22.suse.cz> <20170926172610.GA26694@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 934 Lines: 22 On Tue 26-09-17 20:37:37, Tim Hockin wrote: [...] > I feel like David has offered examples here, and many of us at Google > have offered examples as long ago as 2013 (if I recall) of cases where > the proposed heuristic is EXACTLY WRONG. I do not think we have discussed anything resembling the current approach. And I would really appreciate some more examples where decisions based on leaf nodes would be EXACTLY WRONG. > We need OOM behavior to kill in a deterministic order configured by > policy. And nobody is objecting to this usecase. I think we can build a priority policy on top of leaf-based decision as well. The main point we are trying to sort out here is a reasonable semantic that would work for most workloads. Sibling based selection will simply not work on those that have to use deeper hierarchies for organizational purposes. I haven't heard a counter argument for that example yet. -- Michal Hocko SUSE Labs