From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04837C43381 for ; Fri, 15 Mar 2019 03:43:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D328921872 for ; Fri, 15 Mar 2019 03:43:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727265AbfCODne (ORCPT ); Thu, 14 Mar 2019 23:43:34 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:46935 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726958AbfCODne (ORCPT ); Thu, 14 Mar 2019 23:43:34 -0400 Received: by mail-ot1-f67.google.com with SMTP id c18so7163971otl.13 for ; Thu, 14 Mar 2019 20:43:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=m1cM0hD0iaSSll7TNk9VjvZsrohSkbKY0TH6w+tjBEk=; b=QhrFV5jrZQj/09bQV/juO8BV3ElPFGbwUUvBG3h+1JT4iq9EgX15+aij9zXYmWryOS cYCwgRZ8rIX5eelQlZVs+Imj++0x3fS8zUSXJi1Zr3xdqBozGPukybHIeA2ntAnBboR/ 2eq2/GII3e6j/huDzdXzgIxGEdD88PLZ0h4DeM7AcTwMcSWZDwMrkeo/sZj5nVOgcl1W 9/ho5lL9u5FaTVXnHe1JQdT2XsBNNytR6+1qAbzq5CXiG9vE6HqrKXs6zVoS4yQ7ISK/ OG5mhSyeQ6BukBtWf1QcVUMFi78VqHPM2o+OeztVrEascMZmhegIlO/GPMc63bvSY0Oo 2jdw== X-Gm-Message-State: APjAAAUQ+JUsWhXOfstsXbGze9RU3T/1KoRa0uh1eYxOhI4xIKj/Bj81 7BZsZZ7ujEp2NF77NHIQXcI= X-Google-Smtp-Source: APXvYqxvFJBHD9s4I0eNbzqgQHsFbu7W9iolo8f3gFUJWFxlYyIzoe68S2SHXmshZ12diLwPvICVOA== X-Received: by 2002:a9d:64d0:: with SMTP id n16mr846588otl.268.1552621413062; Thu, 14 Mar 2019 20:43:33 -0700 (PDT) Received: from sultan-box.localdomain ([107.193.118.89]) by smtp.gmail.com with ESMTPSA id i9sm336461otl.43.2019.03.14.20.43.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Mar 2019 20:43:32 -0700 (PDT) Date: Thu, 14 Mar 2019 20:43:28 -0700 From: Sultan Alsawaf To: Joel Fernandes Cc: Tim Murray , Michal Hocko , Suren Baghdasaryan , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Christian Brauner , Ingo Molnar , Peter Zijlstra , LKML , "open list:ANDROID DRIVERS" , linux-mm , kernel-team , Steven Rostedt Subject: Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android Message-ID: <20190315034328.GA3171@sultan-box.localdomain> References: <20190311175800.GA5522@sultan-box.localdomain> <20190311204626.GA3119@sultan-box.localdomain> <20190312080532.GE5721@dhcp22.suse.cz> <20190312163741.GA2762@sultan-box.localdomain> <20190314204911.GA875@sultan-box.localdomain> <20190315025448.GA3378@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190315025448.GA3378@google.com> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 14, 2019 at 10:54:48PM -0400, Joel Fernandes wrote: > I'm not sure if that makes much semantic sense for how the signal handling is > supposed to work. Imagine a parent sends SIGKILL to its child, and then does > a wait(2). Because the SIGKILL blocks in your idea, then the wait cannot > execute, and because the wait cannot execute, the zombie task will not get > reaped and so the SIGKILL senders never gets unblocked and the whole thing > just gets locked up. No? I don't know it just feels incorrect. Block until the victim becomes a zombie instead. > Further, in your idea adding stuff to task_struct will simply bloat it - when > this task can easily be handled using eBPF without making any kernel changes. > Either by probing sched_process_free or sched_process_exit tracepoints. > Scheduler maintainers generally frown on adding stuff to task_struct > pointlessly there's a good reason since bloating it effects the performance > etc, and something like this would probably never be ifdef'd out behind a > CONFIG. Adding something to task_struct is just the easiest way to test things for experimentation. This can be avoided in my suggestion by passing the pointer to a completion via the relevant functions, and then completing it at the time the victim transitions to a zombie state. I understand it's possible to use eBPF for this, but it seems kind of messy since this functionality is something that I think others would want provided by the kernel (i.e., anyone using PSI to implement their own OOM killer daemon similar to LMKD). Thanks, Sultan