[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190411170540.GA5136@cmpxchg.org>
Date: Thu, 11 Apr 2019 13:05:40 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org,
mhocko@...e.com, rientjes@...gle.com, yuzhoujian@...ichuxing.com,
jrdr.linux@...il.com, guro@...com,
penguin-kernel@...ove.sakura.ne.jp, ebiederm@...ssion.com,
shakeelb@...gle.com, christian@...uner.io, minchan@...nel.org,
timmurray@...gle.com, dancol@...gle.com, joel@...lfernandes.org,
jannh@...gle.com, linux-mm@...ck.org,
lsf-pc@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
kernel-team@...roid.com
Subject: Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited
process killing
On Thu, Apr 11, 2019 at 08:33:13AM -0700, 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 SIGKILL
> > 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?
I agree with this. The oom reaper mostly does work the exiting task
would have to do anyway, so this shouldn't be measurably more
expensive to do it per default. I wouldn't want to add a new interface
unless we really do need that type of control.
Powered by blists - more mailing lists