Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp468266yba; Fri, 12 Apr 2019 07:12:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqzlbBcFdjj/cKNsWL5U1FUe7vPb5vj+I3bnvM3njx/1i2Ev6gwkhn2nmqTyZ6wmgkNb3pYs X-Received: by 2002:a62:47d0:: with SMTP id p77mr57068882pfi.95.1555078351937; Fri, 12 Apr 2019 07:12:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555078351; cv=none; d=google.com; s=arc-20160816; b=zNtQRxhpk8kWQsmv5APVVJhEnU40qq7oIoUBw273GeyGWGdkBWRZx5EJyGD23IKfq8 kmj/TlKvt9SER3Qli8Ak9eoODqs8p2nXHWl2kHjj800RBRYfh4D39nXo4IpHQ5sFi7kX iWwuYNjQDpyW/YkKwUj0s5etsf9ZlIVO+ORWbHj5QmZs4p6CRLo/QNmrhArfp4sPptQX kScq1Tn3S8SuS2JPzO0p4cfcAmPdg6ozH7YjEvsEJmc+h1dJK84iGKNDty8cfs7NqGvj L1NTOOBA/ejNN+FIHMbti77iRT8rE9v8jEuQbkrbR/+HhyRPI2gXXhpyoVhpS2ab383+ rZUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=90DhyNOjYKUio3/9dm7oyIW5bfCoyTnkGuxR/xjlLUQ=; b=UIAPwBHCgiIvXwUxFSEfl7oijn7jmKn/PQM0q0kjhCmXaPhIJPTBbHrxRM+aw3AJCJ HrQg9iBGXXitvkMFo5Esjsrrr+hu2iTLLl/QUbNWT5GtvhCqTD0+C9YWKNxB6T3NH+2o XdhUChO7pRZF1HgSuC9+mzwTQBjtxuBYz2G2Dxqj1HV9webDmjdvco1QF4Gk0l2ChWSF LyNzOnyzaJEHhdLPl5k+EP6/DJRZQeJAtIBZZPLuXMaTjsxru8UQHNmqJ2kugOIwwaxL QNjSZeaveHbBGSM3De1viNfshZMXucJXmmLJ6t7oYpJh2ISWokzJa/XQdttIxyuK6WX1 qKhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Ut+BU82T; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id q8si36538815pgp.480.2019.04.12.07.12.15; Fri, 12 Apr 2019 07:12:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Ut+BU82T; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1726914AbfDLOKW (ORCPT + 99 others); Fri, 12 Apr 2019 10:10:22 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:37857 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726850AbfDLOKV (ORCPT ); Fri, 12 Apr 2019 10:10:21 -0400 Received: by mail-wr1-f65.google.com with SMTP id w10so12169497wrm.4 for ; Fri, 12 Apr 2019 07:10:20 -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:content-transfer-encoding; bh=90DhyNOjYKUio3/9dm7oyIW5bfCoyTnkGuxR/xjlLUQ=; b=Ut+BU82ToY63AFh0Jd7IVp0QYUoXU6aJ4Jqho2HFukbN68H9nrlT6/uWhys/uEdm9P 0OeJeAOWj5z4jTcZRBdqYosDVq0aAhb0nJD6k2HCLVVDOG3O8hTl33pidDWNP41+el4z CZgzBAAtmKUfThyobUgavdz2MroFuP9chylGrkQvLRAMXcCpZLN7dopM/s5b4pcKKTdI xqgmHMq5aqXE9T38aLG7t3KX3FV5tRDXuU2oKtGApG+Gk9crSchMAXHFhknZqQkDhq8Q patpTm9UYpR+tzj4k4bPRO/4hQeLsrG2EHTiSXPmEGp8zDYiCXJzyCFOi2EdlMQQa2l/ RQ8Q== 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:content-transfer-encoding; bh=90DhyNOjYKUio3/9dm7oyIW5bfCoyTnkGuxR/xjlLUQ=; b=Sh4+9k+1G3vxkiGqTlOtrT+cV0E2s03gY9cJC/+9gyUquPTuBv5Lu4bJpbiKXjDZ3q BKqLs5LhdmkbXjP8B++Mup2OuwSLDcHVuvCFEhZHbRXWhnivekbhZgk2Sqj2HNLNXUFu 81gQr5TAayDIJXgLvxmISyrWViU+mzLBIhHS4ku/Qs0cR+5101PUvBa1SqHAauCMxrYz dXNQdXkfWYKGKAcZv62x2ELzdSeR2XbkZCwSO3jlGzN+yS44U9Qdf7FkCBre2bfsfdxc WiFxGKZgDwmv91eEhKPYZdILBEO1tFippl9Afxl3y9ueJcakAl+HX2f/LY8agSu/NJ6h 6OGA== X-Gm-Message-State: APjAAAVoHLwHVdE3ja1ULXmuKlLF5DZl71hi3uARvJtHoB9mIFNxZMr3 2L95R0S2cLZ8JvL2F095bIf+iPVEpT7k0LF0EcbKbw== X-Received: by 2002:adf:f98d:: with SMTP id f13mr36647579wrr.98.1555078219540; Fri, 12 Apr 2019 07:10:19 -0700 (PDT) MIME-Version: 1.0 References: <20190411014353.113252-1-surenb@google.com> <20190411014353.113252-3-surenb@google.com> <20190411153313.GE22763@bombadil.infradead.org> <20190412065314.GC13373@dhcp22.suse.cz> In-Reply-To: <20190412065314.GC13373@dhcp22.suse.cz> From: Suren Baghdasaryan Date: Fri, 12 Apr 2019 07:10:08 -0700 Message-ID: Subject: Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing To: Michal Hocko Cc: Matthew Wilcox , Andrew Morton , David Rientjes , yuzhoujian@didichuxing.com, Souptick Joarder , Roman Gushchin , Johannes Weiner , Tetsuo Handa , "Eric W. Biederman" , Shakeel Butt , Christian Brauner , Minchan Kim , Tim Murray , Daniel Colascione , Joel Fernandes , Jann Horn , linux-mm , lsf-pc@lists.linux-foundation.org, LKML , kernel-team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 11, 2019 at 11:53 PM Michal Hocko wrote: > > On Thu 11-04-19 08:33:13, Matthew Wilcox wrote: > > On Wed, Apr 10, 2019 at 06:43:53PM -0700, Suren Baghdasaryan wrote: > > > Add new SS_EXPEDITE flag to be used when sending SIGKILL via > > > pidfd_send_signal() syscall to allow expedited memory reclaim of the > > > victim process. The usage of this flag is currently limited to SIGKIL= L > > > signal and only to privileged users. > > > > What is the downside of doing expedited memory reclaim? ie why not do = it > > every time a process is going to die? > > Well, you are tearing down an address space which might be still in use > because the task not fully dead yeat. So there are two downsides AFAICS. > Core dumping which will not see the reaped memory so the resulting > coredump might be incomplete. And unexpected #PF/gup on the reaped > memory will result in SIGBUS. These are things that we have closed our > eyes in the oom context because they likely do not matter. If we want to > use the same technique for other usecases then we have to think how much > that matter again. > Sorry, resending with corrected settings... After some internal discussions we realized that there is one additional downside of doing reaping unconditionally. If this async reaping is done on a more efficient and energy hungrier CPU irrespective of urgency of the kill it should end up costing more power overall (I=E2=80=99m referring here to assimetric architectures like = ARM big.LITTLE). Obviously quantifying that cost is not easy as it depends on the usecase and a particular system but it won=E2=80=99t be zero. So I think we will need some gating condition after all. > -- > Michal Hocko > SUSE Labs > > -- > You received this message because you are subscribed to the Google Groups= "kernel-team" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >