From: Michal Hocko <mhocko@suse.cz>
To: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Cong Wang <xiyou.wangcong@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Patch v4 1/2] freezer: check OOM kill while being frozen
Date: Mon, 15 Sep 2014 16:28:21 +0200 [thread overview]
Message-ID: <20140915142821.GF19976@dhcp22.suse.cz> (raw)
In-Reply-To: <20140912234846.GA28183@mtj.dyndns.org>
On Sat 13-09-14 08:48:46, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Sep 10, 2014 at 03:24:17PM +0200, Michal Hocko wrote:
> > What do you think about this way to help distinguish kernel threads and
> > user processes and keep the future maintenance of freezer saner?
>
> I'm not sure either way. Please note that we have quite a few
> wrappers around try_to_freeze() - freezable_schedule*() and
> wait_event_freezable*() - and several places where a userland can be
> frozen.
I wasn't aware of those until I discovered freezer_count and company. I
didn't get to study why we need so many freezing point in the kernel yet
and whether they are safe at all.
> Are we gonna introduce an alternate versions for all of them?
Are they intended for kernel threads in the first place? The primary
objective seems to be to not wake up user tasks just to put them into
the fridge when you know they are in a "deep" sleep currently. Kernel
threads know they might freeze themselves when returning from schedule,
no?
freezable_schedule{_timeout} seem to be used only by user tasks AFAICS.
freezable_schedule_unsafe seems to be more complicated due to nfs and
cifs but both of them are checking for fatal signal pending and return
ERESTARTSYS which looks like userspace stuff. So maybe we do not need
any alternate version for kernel threads.
I haven't check the workqueue_freezable API.
> What do we actually gain?
I thought we could easily document and add some rules to where
try_to_freeze can be called from for userspace tasks. Kernel threads
know when they are safe to get frozen but we should be more careful
about user tasks. Whether that can be enforced by an API is a question.
I do admit this much more complicated than I originally anticipated.
try_to_freeze should be a nice barrier where you know that waking into
a new world is safe for the caller (there is no state crossing the
freezing point). Whether a separate API makes this happen is an open
question. I would hope for much higher bar for adding new freezing
points for users tasks as those are more tricky to check.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2014-09-15 14:28 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 22:30 Cong Wang
2014-09-04 22:30 ` [Patch v4 2/2] freezer: remove obsolete comments in __thaw_task() Cong Wang
2014-09-05 9:45 ` Michal Hocko
2014-09-05 14:09 ` Tejun Heo
2014-09-05 14:08 ` [Patch v4 1/2] freezer: check OOM kill while being frozen Tejun Heo
2014-09-05 16:31 ` Cong Wang
2014-09-05 18:00 ` Tejun Heo
2014-09-05 18:12 ` Cong Wang
2014-09-05 22:45 ` Tejun Heo
2014-09-05 23:32 ` Rafael J. Wysocki
2014-09-08 17:40 ` Cong Wang
2014-09-08 20:54 ` Rafael J. Wysocki
2014-09-08 20:58 ` Cong Wang
2014-09-08 21:53 ` Rafael J. Wysocki
2014-09-08 22:22 ` Tejun Heo
2014-09-08 22:48 ` Rafael J. Wysocki
2014-09-08 22:50 ` Tejun Heo
2014-09-08 23:15 ` Rafael J. Wysocki
2014-09-08 23:00 ` Cong Wang
2014-09-08 23:23 ` Rafael J. Wysocki
2014-09-08 23:16 ` Cong Wang
2014-09-08 23:42 ` Rafael J. Wysocki
2014-09-08 23:29 ` Cong Wang
2014-09-08 23:59 ` Rafael J. Wysocki
2014-09-10 20:30 ` Cong Wang
2014-09-10 23:38 ` Rafael J. Wysocki
2014-09-10 23:20 ` Cong Wang
2014-09-11 16:30 ` Michal Hocko
2014-09-12 23:59 ` Tejun Heo
2014-09-14 16:43 ` Rafael J. Wysocki
2014-09-15 0:56 ` Tejun Heo
2014-09-15 3:34 ` Rafael J. Wysocki
2014-09-15 9:36 ` Michal Hocko
2014-09-16 22:55 ` Cong Wang
2014-09-22 8:21 ` Michal Hocko
2014-09-09 15:16 ` Michal Hocko
2014-09-09 15:23 ` Tejun Heo
2014-09-09 16:06 ` Michal Hocko
2014-09-09 16:46 ` Tejun Heo
2014-09-09 17:12 ` Michal Hocko
2014-09-09 20:53 ` Rafael J. Wysocki
2014-09-10 13:24 ` Michal Hocko
2014-09-11 13:08 ` Michal Hocko
2014-09-11 14:17 ` Rafael J. Wysocki
2014-09-11 14:04 ` Michal Hocko
2014-09-11 14:26 ` Rafael J. Wysocki
2014-09-11 14:10 ` Michal Hocko
2014-09-11 14:32 ` Rafael J. Wysocki
2014-09-11 14:28 ` Michal Hocko
2014-09-11 14:52 ` Rafael J. Wysocki
2014-09-11 14:45 ` Michal Hocko
2014-09-14 16:39 ` Rafael J. Wysocki
2014-09-12 23:48 ` Tejun Heo
2014-09-15 14:28 ` Michal Hocko [this message]
2014-09-16 5:56 ` Tejun Heo
2014-09-09 20:48 ` Rafael J. Wysocki
2014-09-10 5:21 ` Cong Wang
2014-09-05 16:43 ` Cong Wang
2014-09-05 16:54 ` Michal Hocko
2014-09-15 11:22 ` Michal Hocko
2014-09-16 22:58 ` Cong Wang
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=20140915142821.GF19976@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.com \
--cc=rjw@rjwysocki.net \
--cc=tj@kernel.org \
--cc=xiyou.wangcong@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome