From: Marco Ballesio <balejs@google.com>
To: Daniel Colascione <dancol@google.com>
Cc: Tejun Heo <tj@kernel.org>, Roman Gushchin <guro@fb.com>,
cgroups@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>,
lizefan@huawei.com, Johannes Weiner <hannes@cmpxchg.org>,
Jonathan Corbet <corbet@lwn.net>,
rjw@rjwysocki.net, Pavel Machek <pavel@ucw.cz>,
len.brown@intel.com,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
linux-pm@vger.kernel.org, Minchan Kim <minchan@google.com>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH] cgroup-v1: freezer: optionally killable freezer
Date: Fri, 20 Mar 2020 13:10:38 -0700 [thread overview]
Message-ID: <20200320201038.GB79184@google.com> (raw)
In-Reply-To: <CAKOZuevzE=0Oa8gn--rkVJ8t69S+o2vK--pki65XXg6EVuOhMQ@mail.gmail.com>
On Wed, Mar 11, 2020 at 10:46:15AM -0700, Daniel Colascione wrote:
> On Tue, Mar 3, 2020 at 5:48 AM Tejun Heo <tj@kernel.org> wrote:
> >
> > Hello,
> >
> > On Wed, Feb 19, 2020 at 10:32:31AM -0800, Marco Ballesio wrote:
> > > @@ -94,6 +94,18 @@ The following cgroupfs files are created by cgroup freezer.
> > > Shows the parent-state. 0 if none of the cgroup's ancestors is
> > > frozen; otherwise, 1.
> > >
> > > +* freezer.killable: Read-write
> > > +
> > > + When read, returns the killable state of a cgroup - "1" if frozen
> > > + tasks will respond to fatal signals, or "0" if they won't.
> > > +
> > > + When written, this property sets the killable state of the cgroup.
> > > + A value equal to "1" will switch the state of all frozen tasks in
> > > + the cgroup to TASK_INTERRUPTIBLE (similarly to cgroup v2) and will
> > > + make them react to fatal signals. A value of "0" will switch the
> > > + state of frozen tasks to TASK_UNINTERRUPTIBLE and they won't respond
> > > + to signals unless thawed or unfrozen.
> >
> > As Roman said, I'm not too sure about adding a new cgroup1 freezer
> > interface at this point. If we do this, *maybe* a mount option would
> > be more minimal?
>
> I'd still prefer a cgroup flag. A mount option is a bigger
> compatibility risk and isn't really any simpler than another cgroup
> flag. A mount option will affect anything using the cgroup mount
> point, potentially turning non-killable frozen processes into killable
> ones unexpectedly. (Sure, you could mount multiple times, but only one
> location is canonical, and that's the one that's going to get the flag
> flipped.) A per-cgroup flag allows people to opt into the new behavior
> only in specific contexts, so it's safer.
It might also be desirable for userland to have a way to modify the behavior of
an already mounted v1 freezer.
Tejun, would it be acceptable to have a flag but disable it by default, hiding
it behind a kernel configuration option?
next prev parent reply other threads:[~2020-03-20 20:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 18:32 [PATCH] cgroup-v1: freezer: optionally killable freezer Marco Ballesio
2020-02-19 18:32 ` Marco Ballesio
[not found] ` <20200219183231.50985-1-balejs-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-02-29 0:51 ` Marco Ballesio
2020-02-29 0:51 ` Marco Ballesio
[not found] ` <20200229005131.GB9813-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-02-29 18:43 ` Roman Gushchin
2020-02-29 18:43 ` Roman Gushchin
[not found] ` <20200229184300.GA484762-lLJQVQxiE4uLfgCeKHXN1g2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2020-03-01 16:20 ` Marco Ballesio
2020-03-01 16:20 ` Marco Ballesio
[not found] ` <20200301162003.GA186618-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-03-02 16:53 ` Roman Gushchin
2020-03-02 16:53 ` Roman Gushchin
2020-03-02 17:46 ` Suren Baghdasaryan
2020-03-02 18:27 ` Roman Gushchin
2020-03-02 18:27 ` Roman Gushchin
2020-03-03 13:48 ` Tejun Heo
2020-03-03 13:48 ` Tejun Heo
2020-03-11 17:46 ` Daniel Colascione
2020-03-20 20:10 ` Marco Ballesio [this message]
2020-03-24 18:26 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200320201038.GB79184@google.com \
--to=balejs@google.com \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dancol@google.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=len.brown@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=minchan@google.com \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=surenb@google.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.