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=-11.4 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,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 E31B1C2D0A3 for ; Tue, 3 Nov 2020 21:41:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 88B4B22384 for ; Tue, 3 Nov 2020 21:41:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="FdUvjbjL" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732798AbgKCVkz (ORCPT ); Tue, 3 Nov 2020 16:40:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732748AbgKCVky (ORCPT ); Tue, 3 Nov 2020 16:40:54 -0500 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78187C0617A6 for ; Tue, 3 Nov 2020 13:40:53 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id s9so19975872wro.8 for ; Tue, 03 Nov 2020 13:40:53 -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=UujFYQwrAMAwi1/OCKFtTp32QIC/tCBtqm1aq3KAJ18=; b=FdUvjbjLJoPJViFWAGZQTYBxNYPCG2lrEX+eW+1JbafAofaJfmaF34xRbhMStCu1bw Q8y8dUQmIvl4HybqP4JQ2sEemewRBCRFSV7WpefnD+epD106SUeDvcyPNvvMSuxqlAki eZy07p1662luyVqnaCsH8fMg+HsoFxrC3o3qXw4wGlXogHOm6XRfrRpwjkMHyttr4Pp9 c+ohCfM4BXsHV41o1jEPT10BBk6ZBWClev2C+qrSzLNS3y0o4TsTxRr9skWqurJOH1z9 3CAVCbPHbZkzJJeyW6Bkl2RQjSilQ/VXgfG0+nhgDaWQOq78Nm0zvZaB+n71rMEEQIDd rkQw== 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=UujFYQwrAMAwi1/OCKFtTp32QIC/tCBtqm1aq3KAJ18=; b=iigeDO6G+91JXEkZ7t8hMFj+0PuRyjpkclqnTHaLeZMKcGhON6MzJ497hWthOIjHWe v0Pcj0ePPdHDQGP+jIRmOGFXF1cQGzQ3tmn0KeqslODqTYbnIadN31r0KLogKASpXSRZ iv0FbQIJCvbBJIqalF8xSXnQSdS5i6wUgQ+PJ2OFtfru7yKHidV1AsMP7CbaM9ci/Z8e pI9rq82RMfRMxld6jEJsi5E/AmeeS4A3tgEYHan0FcfQPw4cxbxyP5e3jRYUV7Hn/hfv pKDsW12eZQPd4Mnuy9K7HlFgAObjizGQZYywEJZk5M6MBucmvFSjqulArXtPIucbaIaX aeFQ== X-Gm-Message-State: AOAM532Hr6TKgVk8CPmb66Ob83xoXDi0qERla4CP4BFCF9OvyiAHkTmn XbWUfO67FWcAIllNwS1NRwcjAf7EfwSyiAQyv1zHHQ== X-Google-Smtp-Source: ABdhPJwwE5qbcx0FJgRwt8ysoKwO12F59BUj6qqo925IYvPZ1whgXvzlaDVmywWxSx45wVl1QcVcY4kSPyjBPA1lUQU= X-Received: by 2002:adf:a501:: with SMTP id i1mr27790501wrb.162.1604439651996; Tue, 03 Nov 2020 13:40:51 -0800 (PST) MIME-Version: 1.0 References: <20201014120937.GC4440@dhcp22.suse.cz> <20201015092030.GB22589@dhcp22.suse.cz> <20201103093550.GE21990@dhcp22.suse.cz> <20201103213228.GB1631979@google.com> In-Reply-To: <20201103213228.GB1631979@google.com> From: Suren Baghdasaryan Date: Tue, 3 Nov 2020 13:40:41 -0800 Message-ID: Subject: Re: [RFC]: userspace memory reaping To: Minchan Kim Cc: Michal Hocko , linux-api@vger.kernel.org, linux-mm , Andrew Morton , David Rientjes , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Rik van Riel , Christian Brauner , Oleg Nesterov , Tim Murray , kernel-team , LKML , Mel Gorman Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, Nov 3, 2020 at 1:32 PM Minchan Kim wrote: > > On Tue, Nov 03, 2020 at 10:35:50AM +0100, Michal Hocko wrote: > > On Mon 02-11-20 12:29:24, Suren Baghdasaryan wrote: > > [...] > > > To follow up on this. Should I post an RFC implementing SIGKILL_SYNC > > > which in addition to sending a kill signal would also reap the > > > victim's mm in the context of the caller? Maybe having some code will > > > get the discussion moving forward? > > > > Yeah, having a code, even preliminary, might help here. This definitely > > needs a good to go from process management people as that proper is land > > full of surprises... > > Just to remind a idea I suggested to reuse existing concept > > fd = pidfd_open(victim process) > fdatasync(fd); > close(fd); > Yep, I just posted a comment about that. I think though your above sequence is missing a pidfd_send_signal(fd, SIGKILL) before the fdatasync(fd)... Not sure if fdatasync(pidfd) or fsync(pidfd) would be more appropriate for this but will use one and we can discuss details in the RFC with the code. Thanks!