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=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no 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 551B3C56202 for ; Wed, 18 Nov 2020 19:58:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2A2B246C8 for ; Wed, 18 Nov 2020 19:58:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HSfuIYzT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2A2B246C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 521416B005D; Wed, 18 Nov 2020 14:58:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D2566B0068; Wed, 18 Nov 2020 14:58:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E7DC6B006C; Wed, 18 Nov 2020 14:58:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id 12D5F6B005D for ; Wed, 18 Nov 2020 14:58:39 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id AD499180AD837 for ; Wed, 18 Nov 2020 19:58:38 +0000 (UTC) X-FDA: 77498601516.22.sea10_4a0b0732733c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 6FA6C1801997C for ; Wed, 18 Nov 2020 19:58:38 +0000 (UTC) X-HE-Tag: sea10_4a0b0732733c X-Filterd-Recvd-Size: 5716 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Nov 2020 19:58:37 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id l1so3375290wrb.9 for ; Wed, 18 Nov 2020 11:58:37 -0800 (PST) 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=a0R930kNYjqnavMF/KBPQVusHU1NjslAYSOCWdpyJ04=; b=HSfuIYzTTaTm27qs+m3sYY0AB2lkoYN+yZmn3aYs/SNgCxiRCa8OfVemFUCsnEfJ3G gzmGaAY1Ah9ppsUIaq4UB+yFR7OcgT2UqbZ1FJHHctPpLw/vwXfQKVpk41362nHk/dfz Z2inWgK+Vb//4DMknD0TXOgo6bnJLZ+CmZHPvRGtBsDo2n0XBnbSMmA4KSibgFIHhHdQ sYk7dJUIDCmgjS90IMCXUeJDtlaCSip6BaPk9ff6ITwi0frdDNddUBgnS5FfQEOOAMHU iEQ2hQQ+2Qc1ID3BKdIYTQviazP6xZH7WLAVkqSW3b0UlgFI3i3MZdzdCyYRo7DUziX7 /Dzw== 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=a0R930kNYjqnavMF/KBPQVusHU1NjslAYSOCWdpyJ04=; b=DZyYYv6QimShyOZ4HWP6DGPu48nglakI39h97sIN4ZVx4CGGAn+JwmeODxo98fJ6R/ ene6921OLtPcOrmhojro/sfnDYgURbRmon6ZRrtHRKoipEN9vUXF1E7xMIVQR2JBvSLa tuCq/fCy+ilD9cC8DzA5SfAML3s4iTr9gGiZx8UU9vhrzFHtObOFb3tYBejrJUqQV0wU /DBURhUD6HuyG3tP3RSyBtWppl+nQG/EhCJ9A+vIfRRYeoYAID0IzJ6QEfFcjmBfXB7V piI/zmdOcK2mjmk1xgWYlGgvF3Xc7EfT5ueZbJiovYQBg+yv2q+1zKax2zEWqGYyZbLG XUgA== X-Gm-Message-State: AOAM532/NhEQyecAFDsBHBQ9iCZsQUpqpTJuVjrySx0eV8W8kE2zjQdU QWzwr/9fQvGfEgysL25oN7hweeXwdhgxVtyIwHcclrFmcoSiXw== X-Google-Smtp-Source: ABdhPJwN1+sRNrKHv4pWi7GszYiUiM0BqmVDZTAlh1f1JsdOfBzXgX31DLoX4X6KxSYKVFVZx4YHKaRz4n08K+i0vM0= X-Received: by 2002:a5d:4a50:: with SMTP id v16mr6536380wrs.106.1605729100247; Wed, 18 Nov 2020 11:51:40 -0800 (PST) MIME-Version: 1.0 References: <20201113173448.1863419-1-surenb@google.com> <20201113155539.64e0af5b60ad3145b018ab0d@linux-foundation.org> <20201113170032.7aa56ea273c900f97e6ccbdc@linux-foundation.org> <20201113171810.bebf66608b145cced85bf54c@linux-foundation.org> <20201113181632.6d98489465430a987c96568d@linux-foundation.org> <20201118154334.GT12284@dhcp22.suse.cz> <20201118193233.GV12284@dhcp22.suse.cz> In-Reply-To: <20201118193233.GV12284@dhcp22.suse.cz> From: Suren Baghdasaryan Date: Wed, 18 Nov 2020 11:51:29 -0800 Message-ID: Subject: Re: [PATCH 1/1] RFC: add pidfd_send_signal flag to reclaim mm while killing a process To: Michal Hocko Cc: Andrew Morton , David Rientjes , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Rik van Riel , Christian Brauner , Oleg Nesterov , Tim Murray , linux-api@vger.kernel.org, linux-mm , LKML , kernel-team , Minchan Kim Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Nov 18, 2020 at 11:32 AM Michal Hocko wrote: > > On Wed 18-11-20 11:22:21, Suren Baghdasaryan wrote: > > On Wed, Nov 18, 2020 at 11:10 AM Michal Hocko wrote: > > > > > > On Fri 13-11-20 18:16:32, Andrew Morton wrote: > > > [...] > > > > It's all sounding a bit painful (but not *too* painful). But to > > > > reiterate, I do think that adding the ability for a process to shoot > > > > down a large amount of another process's memory is a lot more generally > > > > useful than tying it to SIGKILL, agree? > > > > > > I am not sure TBH. Is there any reasonable usecase where uncoordinated > > > memory tear down is OK and a target process which is able to see the > > > unmapped memory? > > > > I think uncoordinated memory tear down is a special case which makes > > sense only when the target process is being killed (and we can enforce > > that by allowing MADV_DONTNEED to be used only if the target process > > has pending SIGKILL). > > That would be safe but then I am wondering whether it makes sense to > implement as a madvise call. It is quite strange to expect somebody call > a syscall on a killed process. But this is more a detail. I am not a > great fan of a more generic MADV_DONTNEED on a remote process. This is > just too dangerous IMHO. Agree 100% > > > However, the ability to apply other flavors of > > process_madvise() to large memory areas spanning multiple VMAs can be > > useful in more cases. > > Yes I do agree with that. The error reporting would be more tricky but > I am not really sure that the exact reporting is really necessary for > advice like interface. Andrew's suggestion for this special mode to change return semantics to the usual "0 or error code" seems to me like the most reasonable way to deal with the return value limitation. > > > For example in Android we will use > > process_madvise(MADV_PAGEOUT) to "shrink" an inactive background > > process. > > That makes sense to me. > -- > Michal Hocko > SUSE Labs