From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756114AbdIGWDb (ORCPT ); Thu, 7 Sep 2017 18:03:31 -0400 Received: from mail-pg0-f47.google.com ([74.125.83.47]:34184 "EHLO mail-pg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756052AbdIGWD2 (ORCPT ); Thu, 7 Sep 2017 18:03:28 -0400 X-Google-Smtp-Source: ADKCNb5B4kc+wgQ9HZHDEeKxQioZXexkgu1XQthwT7pLeBCko5rKCYv2opCJzMLEra90cLC+KVBxtA== Date: Thu, 7 Sep 2017 15:03:25 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Christopher Lameter cc: Michal Hocko , Johannes Weiner , Roman Gushchin , linux-mm@kvack.org, Vladimir Davydov , 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: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer In-Reply-To: Message-ID: References: <20170904142108.7165-1-guro@fb.com> <20170904142108.7165-6-guro@fb.com> <20170905134412.qdvqcfhvbdzmarna@dhcp22.suse.cz> <20170905215344.GA27427@cmpxchg.org> <20170906082859.qlqenftxuib64j35@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, 7 Sep 2017, Christopher Lameter wrote: > > I am not sure this is how things evolved actually. This is way before > > my time so my git log interpretation might be imprecise. We do have > > oom_badness heuristic since out_of_memory has been introduced and > > oom_kill_allocating_task has been introduced much later because of large > > boxes with zillions of tasks (SGI I suspect) which took too long to > > select a victim so David has added this heuristic. > > Nope. The logic was required for tasks that run out of memory when the > restriction on the allocation did not allow the use of all of memory. > cpuset restrictions and memory policy restrictions where the prime > considerations at the time. > > It has *nothing* to do with zillions of tasks. Its amusing that the SGI > ghost is still haunting the discussion here. The company died a couple of > years ago finally (ok somehow HP has an "SGI" brand now I believe). But > there are multiple companies that have large NUMA configurations and they > all have configurations where they want to restrict allocations of a > process to subset of system memory. This is even more important now that > we get new forms of memory (NVDIMM, PCI-E device memory etc). You need to > figure out what to do with allocations that fail because the *allowed* > memory pools are empty. > We already had CONSTRAINT_CPUSET at the time, this was requested by Paul and acked by him in https://marc.info/?l=linux-mm&m=118306851418425.