Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3574869pxv; Mon, 26 Jul 2021 07:09:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/DkU8i8Kh3RFAeScFpYjYtOekup7NnYc7OutgA/KsXl11NMLLzFbyG1WNvCQWDSCqH0Bg X-Received: by 2002:a05:6602:248f:: with SMTP id g15mr629856ioe.198.1627308543160; Mon, 26 Jul 2021 07:09:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627308543; cv=none; d=google.com; s=arc-20160816; b=FyrjzBez3yUkdlYULr751kSI3D7k/Dl09CiYoWHht6SY+3uPY+q874MVym+jLjPWla smIhPZ+QUkl9Z/A8wEsbIvZC6ow7vBdYOnjItiyG3FvPiV/7v+PFtxOspcG3GssYW4yt 5nC8R3Z2+cOObNAtm+E2vsalT8fTzmou+pwwyfwva3Z4QsjBKXNiiBkMXRtajXSgog1P rTC7fDFSply1faiaoaK5E2apABMgkBh5yDGN0syyqNAvaG2t3z+fNXLO2hHY/D2j0hxo TYHA3RbH0to+vlkwvAFzj0P0pw0Y1XCchwg7LtuaD0dUBjdseG04V0miTODBIiXbgL+F F3aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=TLycPxviRjQS2vlWYgAqhStL9LKdE5LJjJtFS7Jae4Y=; b=NPLZOfbl61vQDAlRUnjTJdC6pRtTVqG9pmd+5SwROWmC7ArP2PsDX3Win6wzQZnyXo 58Yv4F/sfTLU1kU30HWGGCrQWHHhIuc/b6CSJG8K6he/4EdIMehaIPKVEJjbGRzpiVpU muBPFIiuv1UIvpkFnWqN22DqOhRnvnE2poLqRaT5mjx3UyP1DXarAz4HSjyqVattpNty 8NDN74PTVFYaUqLer/8hzlhRUkC0fMsZgFDMEOq7aUSTuxDOVEWVcF88V5kmDbPpCf8l JBZD9Y/XzjteDWA+Z95iRLmx3id01+xd4I2RwK8GeL+VfpVExPEgpfmeaMGp0tI62i6Q 8BoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kM3ffQib; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r7si36122ill.122.2021.07.26.07.08.43; Mon, 26 Jul 2021 07:09:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kM3ffQib; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234126AbhGZNDh (ORCPT + 99 others); Mon, 26 Jul 2021 09:03:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233970AbhGZNDg (ORCPT ); Mon, 26 Jul 2021 09:03:36 -0400 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA5C1C061760 for ; Mon, 26 Jul 2021 06:44:03 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id m9so11321329ljp.7 for ; Mon, 26 Jul 2021 06:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TLycPxviRjQS2vlWYgAqhStL9LKdE5LJjJtFS7Jae4Y=; b=kM3ffQibqdlLWCaxU3irV+dXOOAiJRgpArqXCrZqUlURkhV3Uj7T8ux2Ir7Z9cReit sl0WxaiR7gwq+eJ/XKMu6TRVKV1my3wGtPAGwJ2G3Qm+9koRzZtV+JdcqyUzr2EhIcfX ufHWsMiRjGklH8iHGZD4IGM6CFSx+vFneLC8532Df/g/4zOZ5s5OuUE0gHkaWpz/aIH0 d5KATqF9cmZJGa/LlkElPYuMQubU9BvAUrDd7RNkVvdTbwypVi4BJheSfkGPEY7EHTTD iqyA7t9AjMkRHoUSEBnmRaMdq0wJ7r9mri8PykgK+wl00Zw8d52GCbEaSjmhABtQmzWK jg8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TLycPxviRjQS2vlWYgAqhStL9LKdE5LJjJtFS7Jae4Y=; b=XGvQaf4ucGu783bKd6yp9KqZiPYsu6d+AcEZoxVS3N47T+zGOt+cSXFjDcp2o6GHmB mD/dY8RVrXE1oAmQ4xN8Ct2y1pgwixJGSOS3rjNseKWY/dQkxbluSTIC9HlskS1C9bQV uWmuTCxVnsX6tBMuk3X38usxal5rWpaQ7lCGCwfXD/2lrLZ/9LfsSAVJKGUPTE/+mnKI HMpJSJpYNUutSQEWJExjfNfrTdDCxwcNkO/KgMPwP0hSSVuFKHWyz5uu7rZXf376Y/7q KE9FTUB/UCpkU2EK257dLBbVLZdYix6JREQsxI1uroaCfSvZJp2b64q9tPx0boX4GrbI E6tQ== X-Gm-Message-State: AOAM531YFd628kJuRn62qo/b7RmkOD5FOuUwZTiZy6sWUr0az+VVjXxU zGR+lrVuPm0sFB9ngA+1Qcqna2U9xDU9y8VBD6/rIg== X-Received: by 2002:a2e:85d7:: with SMTP id h23mr12408419ljj.279.1627307041973; Mon, 26 Jul 2021 06:44:01 -0700 (PDT) MIME-Version: 1.0 References: <20210723011436.60960-1-surenb@google.com> In-Reply-To: From: Shakeel Butt Date: Mon, 26 Jul 2021 06:43:50 -0700 Message-ID: Subject: Re: [PATCH v3 1/2] mm: introduce process_mrelease system call To: Michal Hocko Cc: Suren Baghdasaryan , Andrew Morton , David Rientjes , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Rik van Riel , Minchan Kim , Christian Brauner , Christoph Hellwig , Oleg Nesterov , David Hildenbrand , Jann Horn , Andy Lutomirski , Christian Brauner , Florian Weimer , Jan Engelhardt , Tim Murray , Linux API , Linux MM , LKML , kernel-team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 26, 2021 at 12:27 AM Michal Hocko wrote: > [...] > > Is process_mrelease on all of them really necessary? I thought that the > primary reason for the call is to guarantee a forward progress in cases > where the userspace OOM victim cannot die on SIGKILL. That should be > more an exception than a normal case, no? > I am thinking of using this API in this way: On user-defined OOM condition, kill a job/cgroup and unconditionally reap all of its processes. Keep monitoring the situation and if it does not improve go for another kill and reap. I can add additional logic in between kill and reap to see if reap is necessary but unconditionally reaping is more simple. > > > An alternative would be to have a cgroup specific interface for > > reaping similar to cgroup.kill. > > Could you elaborate? > I mentioned this in [1] where I was thinking if it makes sense to overload cgroup.kill to also add the SIGKILLed processes in oom_reaper_list. The downside would be that there will be one thread doing the reaping and the syscall approach allows userspace to reap in multiple threads. I think for now, I would go with whatever Suren is proposing and we can always add more stuff if need arises. [1] https://lore.kernel.org/containers/CALvZod4jsb6bFzTOS4ZRAJGAzBru0oWanAhezToprjACfGm+ew@mail.gmail.com/