From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751195AbdJBL4f (ORCPT ); Mon, 2 Oct 2017 07:56:35 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:43052 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751010AbdJBL4e (ORCPT ); Mon, 2 Oct 2017 07:56:34 -0400 To: shakeelb@google.com, thockin@hockin.org Cc: guro@fb.com, mhocko@kernel.org, hannes@cmpxchg.org, tj@kernel.org, kernel-team@fb.com, rientjes@google.com, linux-mm@kvack.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [v8 0/4] cgroup-aware OOM killer From: Tetsuo Handa References: <20170927074319.o3k26kja43rfqmvb@dhcp22.suse.cz> <20170927162300.GA5623@castle.DHCP.thefacebook.com> In-Reply-To: Message-Id: <201710022056.EJI43796.FSFLOHQJtOVMOF@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Mon, 2 Oct 2017 20:56:31 +0900 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 Shakeel Butt wrote: > I think Tim has given very clear explanation why comparing A & D makes > perfect sense. However I think the above example, a single user system > where a user has designed and created the whole hierarchy and then > attaches different jobs/applications to different nodes in this > hierarchy, is also a valid scenario. One solution I can think of, to > cater both scenarios, is to introduce a notion of 'bypass oom' or not > include a memcg for oom comparision and instead include its children > in the comparison. I'm not catching up to this thread because I don't use memcg. But if there are multiple scenarios, what about offloading memcg OOM handling to loadable kernel modules (like there are many filesystems which are called by VFS interface) ? We can do try and error more casually. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id 7C7546B0033 for ; Mon, 2 Oct 2017 07:56:50 -0400 (EDT) Received: by mail-pf0-f200.google.com with SMTP id g65so840807pfe.9 for ; Mon, 02 Oct 2017 04:56:50 -0700 (PDT) Received: from www262.sakura.ne.jp (www262.sakura.ne.jp. [2001:e42:101:1:202:181:97:72]) by mx.google.com with ESMTPS id j65si9128944iod.89.2017.10.02.04.56.48 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 02 Oct 2017 04:56:49 -0700 (PDT) Subject: Re: [v8 0/4] cgroup-aware OOM killer From: Tetsuo Handa References: <20170927074319.o3k26kja43rfqmvb@dhcp22.suse.cz> <20170927162300.GA5623@castle.DHCP.thefacebook.com> In-Reply-To: Message-Id: <201710022056.EJI43796.FSFLOHQJtOVMOF@I-love.SAKURA.ne.jp> Date: Mon, 2 Oct 2017 20:56:31 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mm@kvack.org List-ID: To: shakeelb@google.com, thockin@hockin.org Cc: guro@fb.com, mhocko@kernel.org, hannes@cmpxchg.org, tj@kernel.org, kernel-team@fb.com, rientjes@google.com, linux-mm@kvack.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Shakeel Butt wrote: > I think Tim has given very clear explanation why comparing A & D makes > perfect sense. However I think the above example, a single user system > where a user has designed and created the whole hierarchy and then > attaches different jobs/applications to different nodes in this > hierarchy, is also a valid scenario. One solution I can think of, to > cater both scenarios, is to introduce a notion of 'bypass oom' or not > include a memcg for oom comparision and instead include its children > in the comparison. I'm not catching up to this thread because I don't use memcg. But if there are multiple scenarios, what about offloading memcg OOM handling to loadable kernel modules (like there are many filesystems which are called by VFS interface) ? We can do try and error more casually. -- 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