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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 7D856C4742C for ; Tue, 3 Nov 2020 21:46:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 30E2421556 for ; Tue, 3 Nov 2020 21:46:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604440010; bh=cw9nFt5dXabR/ne5VwxZMaZK+UGy/SmnfNZELatk+F4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=o8jkM3LrEjbA03fTIfNd6rg/g8tB8KqKYsNHSRWnN9cmnFZbiNWrOk9K5Tu3rbIFv K62wqgiREDo8nuYHs9ZdjRdmojxOb5T9+/YZJtwWDJ5ESFlsxSBhYH0afMkNWzf7cG 0l0qvqxLmy7MXCuGN1d5vYTuiFhCTUcjovAtTrAY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732616AbgKCVqt (ORCPT ); Tue, 3 Nov 2020 16:46:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730363AbgKCVqr (ORCPT ); Tue, 3 Nov 2020 16:46:47 -0500 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32EF5C0613D1; Tue, 3 Nov 2020 13:46:47 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id i26so14746886pgl.5; Tue, 03 Nov 2020 13:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1PpGGoZmrXkX7f7f0JV0lFNqK/EDCekB1Ge7X3zSkxQ=; b=kEeTJrqmvvtmnfuCU25YIXiE75LlH9tArKhnwsc2sNhwLkYnILuVtw9gxIpPueUcLz +UhpHM+8MvKpX4Orvj43d4S3r51vEAyQ1gUNVYsGapQWX9TwQXlcrpdLX6gnv2IFjMXi Fe7/EULFy8TjBYL5q4leSQiJjp5jAvEUHwq/O2mAOx72N43uJLG1+Z8qQwUoteP8xpfS AZjXh83p+5lI+DPL8KJFaHotFr8YillaPC3SUdgj4iHXqmN2Tm3+IAm1ofHM9BfKRBSI Rf499CT/1qCra9AovZnxdb8CfC/Qe99XBfXKR05qFdQqv870zcZCSt8JnB9e5ufxaINM wFmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=1PpGGoZmrXkX7f7f0JV0lFNqK/EDCekB1Ge7X3zSkxQ=; b=gbbAqpqhnahr2OLtCyx8f0LO9b2Z6gRBrUUtXE0KockpYcpJxo9PZb4zp9OCh5ldcb TNgZtEATtv2765BUpttyeGMhaQ9/MvOrutHTvySFT8TpvOdQLFUkOAMhrFnO3FVcF4pH 8slBgnH9Erz9FddLsqUWopJ4Llu2OC5GyN9C5Uj50CbpQRJa4r+hl/zraZF7m2vNXDM0 1YpJGo5Mj0fjwwIQH/rSr7HXO5VwJOTWt/DAJa/P85j5y8HCXuTiOh4NJuTBlVFcJWu5 1jMdkBRXhvS6tduYAf2574VVM6P0sQIhFjMz6tQOm/9jE8pCoV4Rzto55VG0ekaYIBfK 9F9g== X-Gm-Message-State: AOAM532QHInc5yAGXosIBYOMBnd2z8BnGzqq/gyCV9g1/+AugAo9sBGX 8T2VcWN8fz1T52+l2i4e85polVLyx1o= X-Google-Smtp-Source: ABdhPJyy0fb2Z4Agy9VQCUvcVqCyWVPKfTl3LIjTFXE6g/dHUpqtCBFeVLRcCo71EdONI96MLiTafw== X-Received: by 2002:a17:90b:1081:: with SMTP id gj1mr1204800pjb.15.1604440006238; Tue, 03 Nov 2020 13:46:46 -0800 (PST) Received: from google.com ([2620:15c:211:201:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id 92sm103966pjv.32.2020.11.03.13.46.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Nov 2020 13:46:44 -0800 (PST) Sender: Minchan Kim Date: Tue, 3 Nov 2020 13:46:40 -0800 From: Minchan Kim To: Suren Baghdasaryan 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 Subject: Re: [RFC]: userspace memory reaping Message-ID: <20201103214532.GC1631979@google.com> References: <20201014120937.GC4440@dhcp22.suse.cz> <20201015092030.GB22589@dhcp22.suse.cz> <20201103093550.GE21990@dhcp22.suse.cz> <20201103213228.GB1631979@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 03, 2020 at 01:40:41PM -0800, Suren Baghdasaryan wrote: > 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. IMO, fdatasync would be better symantic since fsync invovles metadata (i.e., task_struct, mm_struct and so on). I think what you need is just pages attached to address_space, which sounds like data, not metadata.