[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141106165828.GL7202@dhcp22.suse.cz>
Date: Thu, 6 Nov 2014 17:58:28 +0100
From: Michal Hocko <mhocko@...e.cz>
To: Tejun Heo <tj@...nel.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Cong Wang <xiyou.wangcong@...il.com>,
David Rientjes <rientjes@...gle.com>,
Oleg Nesterov <oleg@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 3/4] OOM, PM: OOM killed task shouldn't escape PM suspend
On Thu 06-11-14 11:33:04, Tejun Heo wrote:
> On Thu, Nov 06, 2014 at 05:31:24PM +0100, Michal Hocko wrote:
> > On Thu 06-11-14 11:12:11, Tejun Heo wrote:
[...]
> > > Draining oom killer then doesn't mean anything, no? OOM killer may
> > > have been disabled and drained but the killed tasks might wake up
> > > after the PM freezer considers them to be frozen, right? What am I
> > > missing?
> >
> > The mutual exclusion between OOM and the freezer will cause that the
> > victim will have TIF_MEMDIE already set when try_to_freeze_tasks even
> > starts. Then freezing_slow_path wouldn't allow the task to enter the
> > fridge so the wake up moment is not really that important.
>
> What if it was already in the freezer?
Good question! You are right that there is a race window until the wake
up then. I will think about this case some more. There is simply no
control on when the task wakes up and freezer will see it as frozen
until then. An immediate way around would be to check for TIF_MEMDIE in
try_to_freeze_tasks.
I have to call it end of the day unfortunately and will be back on
Monday.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists