[Sorry for the late reply, I was mostly offline throughout last week]
On Tue 16-09-14 15:55:48, Cong Wang wrote:
> On Mon, Sep 15, 2014 at 2:36 AM, Michal Hocko wrote:
> > This patch builds on top of Cong Wang's. What do you think?
>
> I think it is should a preliminary of my patch, not a
[Sorry for the late reply, I was mostly offline throughout last week]
On Tue 16-09-14 15:55:48, Cong Wang wrote:
On Mon, Sep 15, 2014 at 2:36 AM, Michal Hocko mho...@suse.cz wrote:
This patch builds on top of Cong Wang's. What do you think?
I think it is should a preliminary of my patch,
On Mon, Sep 15, 2014 at 4:22 AM, Michal Hocko wrote:
> On Thu 04-09-14 15:30:41, Cong Wang wrote:
>> There is a race condition between OOM killer and freezer when
>> they try to operate on the same process, something like below:
>>
>> Process A Process B Process C
>>
On Mon, Sep 15, 2014 at 2:36 AM, Michal Hocko wrote:
> This patch builds on top of Cong Wang's. What do you think?
I think it is should a preliminary of my patch, not a followup. I can carry
this patch for you if you want.
> ---
> From cdf97a20b107ee584352f07274a88d7c3f014ab2 Mon Sep 17
On Mon, Sep 15, 2014 at 2:36 AM, Michal Hocko mho...@suse.cz wrote:
This patch builds on top of Cong Wang's. What do you think?
I think it is should a preliminary of my patch, not a followup. I can carry
this patch for you if you want.
---
From cdf97a20b107ee584352f07274a88d7c3f014ab2 Mon Sep
On Mon, Sep 15, 2014 at 4:22 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 04-09-14 15:30:41, Cong Wang wrote:
There is a race condition between OOM killer and freezer when
they try to operate on the same process, something like below:
Process A Process B Process C
Hello, Michal.
On Mon, Sep 15, 2014 at 04:28:21PM +0200, Michal Hocko wrote:
> > Are we gonna introduce an alternate versions for all of them?
>
> Are they intended for kernel threads in the first place? The primary
There's no restriction in using them and I'm pretty sure some of them
are used
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
On Thu 04-09-14 15:30:41, Cong Wang wrote:
> There is a race condition between OOM killer and freezer when
> they try to operate on the same process, something like below:
>
> Process A Process B Process C
> trigger page fault
> then trigger oom
>
On Mon 15-09-14 05:34:36, Rafael J. Wysocki wrote:
> On Monday, September 15, 2014 09:56:57 AM Tejun Heo wrote:
> > On Sun, Sep 14, 2014 at 06:43:31PM +0200, Rafael J. Wysocki wrote:
> > > On Saturday, September 13, 2014 08:59:35 AM Tejun Heo wrote:
> > > > Doesn't this mean that if PM freezing
On Mon 15-09-14 05:34:36, Rafael J. Wysocki wrote:
On Monday, September 15, 2014 09:56:57 AM Tejun Heo wrote:
On Sun, Sep 14, 2014 at 06:43:31PM +0200, Rafael J. Wysocki wrote:
On Saturday, September 13, 2014 08:59:35 AM Tejun Heo wrote:
Doesn't this mean that if PM freezing and OOM
On Thu 04-09-14 15:30:41, Cong Wang wrote:
There is a race condition between OOM killer and freezer when
they try to operate on the same process, something like below:
Process A Process B Process C
trigger page fault
then trigger oom
B=oom_scan_process_thread()
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.
Hello, Michal.
On Mon, Sep 15, 2014 at 04:28:21PM +0200, Michal Hocko wrote:
Are we gonna introduce an alternate versions for all of them?
Are they intended for kernel threads in the first place? The primary
There's no restriction in using them and I'm pretty sure some of them
are used by
On Monday, September 15, 2014 09:56:57 AM Tejun Heo wrote:
> On Sun, Sep 14, 2014 at 06:43:31PM +0200, Rafael J. Wysocki wrote:
> > On Saturday, September 13, 2014 08:59:35 AM Tejun Heo wrote:
> > > Doesn't this mean that if PM freezing and OOM killing race each other,
> > > the system may hang?
On Sun, Sep 14, 2014 at 06:43:31PM +0200, Rafael J. Wysocki wrote:
> On Saturday, September 13, 2014 08:59:35 AM Tejun Heo wrote:
> > Doesn't this mean that if PM freezing and OOM killing race each other,
> > the system may hang? Driver PM operation may try to allocate memory
> > -> triggers OOM
On Saturday, September 13, 2014 08:59:35 AM Tejun Heo wrote:
> On Thu, Sep 11, 2014 at 06:30:04PM +0200, Michal Hocko wrote:
> > > I am wondering if the folllowing check makes any sense with regarding
> > > to rule out PM freeze:
> > >
> > > if ((!pm_nosig_freezing && !pm_freezing) &&
> >
On Thursday, September 11, 2014 04:45:09 PM Michal Hocko wrote:
> On Thu 11-09-14 16:52:50, Rafael J. Wysocki wrote:
> > On Thursday, September 11, 2014 04:28:22 PM Michal Hocko wrote:
> > > On Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
> > > > On Thursday, September 11, 2014 04:10:51 PM
On Thursday, September 11, 2014 04:45:09 PM Michal Hocko wrote:
On Thu 11-09-14 16:52:50, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:28:22 PM Michal Hocko wrote:
On Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:10:51 PM Michal Hocko
On Saturday, September 13, 2014 08:59:35 AM Tejun Heo wrote:
On Thu, Sep 11, 2014 at 06:30:04PM +0200, Michal Hocko wrote:
I am wondering if the folllowing check makes any sense with regarding
to rule out PM freeze:
if ((!pm_nosig_freezing !pm_freezing)
On Sun, Sep 14, 2014 at 06:43:31PM +0200, Rafael J. Wysocki wrote:
On Saturday, September 13, 2014 08:59:35 AM Tejun Heo wrote:
Doesn't this mean that if PM freezing and OOM killing race each other,
the system may hang? Driver PM operation may try to allocate memory
- triggers OOM - OOM
On Monday, September 15, 2014 09:56:57 AM Tejun Heo wrote:
On Sun, Sep 14, 2014 at 06:43:31PM +0200, Rafael J. Wysocki wrote:
On Saturday, September 13, 2014 08:59:35 AM Tejun Heo wrote:
Doesn't this mean that if PM freezing and OOM killing race each other,
the system may hang? Driver PM
On Thu, Sep 11, 2014 at 06:30:04PM +0200, Michal Hocko wrote:
> > I am wondering if the folllowing check makes any sense with regarding
> > to rule out PM freeze:
> >
> > if ((!pm_nosig_freezing && !pm_freezing) &&
> > cgroup_freezing(current) && test_thread_flag(TIF_MEMDIE))
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
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
On Thu, Sep 11, 2014 at 06:30:04PM +0200, Michal Hocko wrote:
I am wondering if the folllowing check makes any sense with regarding
to rule out PM freeze:
if ((!pm_nosig_freezing !pm_freezing)
cgroup_freezing(current) test_thread_flag(TIF_MEMDIE))
On Wed 10-09-14 13:30:25, Cong Wang wrote:
> On Mon, Sep 8, 2014 at 4:29 PM, Cong Wang wrote:
> > On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki
> > wrote:
> >> On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
> >>> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki
> >>> wrote:
>
On Thu 11-09-14 16:52:50, Rafael J. Wysocki wrote:
> On Thursday, September 11, 2014 04:28:22 PM Michal Hocko wrote:
> > On Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
> > > On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
> > > > On Thu 11-09-14 16:26:56, Rafael J. Wysocki
On Thursday, September 11, 2014 04:28:22 PM Michal Hocko wrote:
> On Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
> > On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
> > > On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
> > > > On Thursday, September 11, 2014 04:04:48 PM
On Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
> On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
> > On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
> > > On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
> > > > On Thu 11-09-14 16:17:56, Rafael J. Wysocki
On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
> On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
> > On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
> > > On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
> > > [...]
> > > > And I'm still wondering if the OOM
On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
[...]
> And I'm still wondering if the OOM killer may be made avoid killing frozen
> tasks.
This is really tricky. OOM killer aims at the biggest memory hog. We
shouldn't ignore it just because it hides into the fridge... So even
if we "fix" oom
On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
> On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
> > On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
> > [...]
> > > And I'm still wondering if the OOM killer may be made avoid killing frozen
> > > tasks.
> >
> > This is
On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
> On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
> [...]
> > And I'm still wondering if the OOM killer may be made avoid killing frozen
> > tasks.
>
> This is really tricky. OOM killer aims at the biggest memory hog. We
>
On Thursday, September 11, 2014 03:08:40 PM Michal Hocko wrote:
> On Wed 10-09-14 15:24:17, Michal Hocko wrote:
> > On Tue 09-09-14 22:53:32, Rafael J. Wysocki wrote:
> > > On Wednesday, September 10, 2014 01:46:58 AM Tejun Heo wrote:
> > > > Hello,
> > > >
> > > > On Tue, Sep 09, 2014 at
On Wed 10-09-14 15:24:17, Michal Hocko wrote:
> On Tue 09-09-14 22:53:32, Rafael J. Wysocki wrote:
> > On Wednesday, September 10, 2014 01:46:58 AM Tejun Heo wrote:
> > > Hello,
> > >
> > > On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
> > > > > Even for userland tasks,
On Wed 10-09-14 15:24:17, Michal Hocko wrote:
On Tue 09-09-14 22:53:32, Rafael J. Wysocki wrote:
On Wednesday, September 10, 2014 01:46:58 AM Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
Even for userland tasks, try_to_freeze() can
On Thursday, September 11, 2014 03:08:40 PM Michal Hocko wrote:
On Wed 10-09-14 15:24:17, Michal Hocko wrote:
On Tue 09-09-14 22:53:32, Rafael J. Wysocki wrote:
On Wednesday, September 10, 2014 01:46:58 AM Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal
On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
[...]
And I'm still wondering if the OOM killer may be made avoid killing frozen
tasks.
This is really tricky. OOM killer aims at the biggest memory hog. We
shouldn't ignore
On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
[...]
And I'm still wondering if the OOM killer may be made avoid killing frozen
tasks.
This is really tricky. OOM
On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
[...]
And I'm still wondering if the OOM killer may be made avoid killing frozen
tasks.
This is really tricky. OOM killer aims at the biggest memory hog. We
shouldn't ignore it just because it hides into the fridge... So even
if we fix oom
On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
[...]
And I'm still wondering if the OOM killer may be
On Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:28:22 PM Michal Hocko wrote:
On Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:04:48 PM Michal Hocko
On Thu 11-09-14 16:52:50, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:28:22 PM Michal Hocko wrote:
On Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
On
On Wed 10-09-14 13:30:25, Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:29 PM, Cong Wang xiyou.wangc...@gmail.com wrote:
On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki r...@rjwysocki.net
wrote:
On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:23 PM,
On Wed, Sep 10, 2014 at 4:38 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 10, 2014 01:30:25 PM Cong Wang wrote:
>> I am wondering if the folllowing check makes any sense with regarding
>> to rule out PM freeze:
>>
>> if ((!pm_nosig_freezing && !pm_freezing) &&
>>
On Wednesday, September 10, 2014 01:30:25 PM Cong Wang wrote:
> On Mon, Sep 8, 2014 at 4:29 PM, Cong Wang wrote:
> > On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki
> > wrote:
> >> On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
> >>> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J.
On Mon, Sep 8, 2014 at 4:29 PM, Cong Wang wrote:
> On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki wrote:
>> On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
>>> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki
>>> wrote:
>>> >
>>> > The reason why it matters for the suspend-time
On Tue 09-09-14 22:53:32, Rafael J. Wysocki wrote:
> On Wednesday, September 10, 2014 01:46:58 AM Tejun Heo wrote:
> > Hello,
> >
> > On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
> > > > Even for userland tasks, try_to_freeze() can currently be anywhere in
> > > > the kernel.
On Tue 09-09-14 22:53:32, Rafael J. Wysocki wrote:
On Wednesday, September 10, 2014 01:46:58 AM Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
Even for userland tasks, try_to_freeze() can currently be anywhere in
the kernel. The frequently
On Mon, Sep 8, 2014 at 4:29 PM, Cong Wang xiyou.wangc...@gmail.com wrote:
On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki r...@rjwysocki.net
wrote:
The
On Wednesday, September 10, 2014 01:30:25 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:29 PM, Cong Wang xiyou.wangc...@gmail.com wrote:
On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki r...@rjwysocki.net
wrote:
On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
On Mon, Sep 8,
On Wed, Sep 10, 2014 at 4:38 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, September 10, 2014 01:30:25 PM Cong Wang wrote:
I am wondering if the folllowing check makes any sense with regarding
to rule out PM freeze:
if ((!pm_nosig_freezing !pm_freezing)
On Tue, Sep 9, 2014 at 1:48 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 10, 2014 12:23:36 AM Tejun Heo wrote:
>> On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
>> > But OOM killer doesn't kill kernel threads as they do not own any
>> > memory. So the check should be
On Wednesday, September 10, 2014 01:46:58 AM Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
> > > Even for userland tasks, try_to_freeze() can currently be anywhere in
> > > the kernel. The frequently used ones are few but there are some odd
> >
> >
On Wednesday, September 10, 2014 12:23:36 AM Tejun Heo wrote:
> On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
> > But OOM killer doesn't kill kernel threads as they do not own any
> > memory. So the check should be safe, no?
>
> Even for userland tasks, try_to_freeze() can
On Wed 10-09-14 01:46:58, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
> > > Even for userland tasks, try_to_freeze() can currently be anywhere in
> > > the kernel. The frequently used ones are few but there are some odd
> >
> > I always thought
Hello,
On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
> > Even for userland tasks, try_to_freeze() can currently be anywhere in
> > the kernel. The frequently used ones are few but there are some odd
>
> I always thought that user space tasks can be in the fridge only on the
>
On Wed 10-09-14 00:23:36, Tejun Heo wrote:
> On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
> > But OOM killer doesn't kill kernel threads as they do not own any
> > memory. So the check should be safe, no?
>
> Even for userland tasks, try_to_freeze() can currently be anywhere in
>
On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
> But OOM killer doesn't kill kernel threads as they do not own any
> memory. So the check should be safe, no?
Even for userland tasks, try_to_freeze() can currently be anywhere in
the kernel. The frequently used ones are few but
On Tue 09-09-14 07:50:12, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
> > Well, not exactly from anywhere. Just from where try_to_freeze() is called
> > I suppose?
>
> Yeap, anywhere try_to_freeze() may be called.
>
> > Which means that if
On Tue 09-09-14 07:50:12, Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
Well, not exactly from anywhere. Just from where try_to_freeze() is called
I suppose?
Yeap, anywhere try_to_freeze() may be called.
Which means that if this is a
On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
But OOM killer doesn't kill kernel threads as they do not own any
memory. So the check should be safe, no?
Even for userland tasks, try_to_freeze() can currently be anywhere in
the kernel. The frequently used ones are few but there
On Wed 10-09-14 00:23:36, Tejun Heo wrote:
On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
But OOM killer doesn't kill kernel threads as they do not own any
memory. So the check should be safe, no?
Even for userland tasks, try_to_freeze() can currently be anywhere in
the
Hello,
On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
Even for userland tasks, try_to_freeze() can currently be anywhere in
the kernel. The frequently used ones are few but there are some odd
I always thought that user space tasks can be in the fridge only on the
way out
On Wed 10-09-14 01:46:58, Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
Even for userland tasks, try_to_freeze() can currently be anywhere in
the kernel. The frequently used ones are few but there are some odd
I always thought that user space
On Wednesday, September 10, 2014 12:23:36 AM Tejun Heo wrote:
On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
But OOM killer doesn't kill kernel threads as they do not own any
memory. So the check should be safe, no?
Even for userland tasks, try_to_freeze() can currently be
On Wednesday, September 10, 2014 01:46:58 AM Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
Even for userland tasks, try_to_freeze() can currently be anywhere in
the kernel. The frequently used ones are few but there are some odd
I always
On Tue, Sep 9, 2014 at 1:48 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, September 10, 2014 12:23:36 AM Tejun Heo wrote:
On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
But OOM killer doesn't kill kernel threads as they do not own any
memory. So the check
On Monday, September 08, 2014 04:29:24 PM Cong Wang wrote:
> On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki wrote:
> > On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
> >> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki
> >> wrote:
> >> >
> >> > The reason why it matters for the
On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki wrote:
> On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
>> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki wrote:
>> >
>> > The reason why it matters for the suspend-time freezing is that we freeze
>> > tasks
>> > to take them out
On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki wrote:
> >
> > The reason why it matters for the suspend-time freezing is that we freeze
> > tasks
> > to take them out of the picture entirely until they are thawed. Therefore
> > we
On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki wrote:
>
> The reason why it matters for the suspend-time freezing is that we freeze
> tasks
> to take them out of the picture entirely until they are thawed. Therefore we
> can't allow them to go back to the picture just for a while until they
On Monday, September 08, 2014 04:00:41 PM Cong Wang wrote:
> On Mon, Sep 8, 2014 at 4:15 PM, Rafael J. Wysocki wrote:
> > On Tuesday, September 09, 2014 07:50:12 AM Tejun Heo wrote:
> >> Hello,
> >>
> >> On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
> >> > Well, not exactly
On Mon, Sep 8, 2014 at 4:15 PM, Rafael J. Wysocki wrote:
> On Tuesday, September 09, 2014 07:50:12 AM Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
>> > Well, not exactly from anywhere. Just from where try_to_freeze() is called
>> > I
On Tuesday, September 09, 2014 07:50:12 AM Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
> > Well, not exactly from anywhere. Just from where try_to_freeze() is called
> > I suppose?
>
> Yeap, anywhere try_to_freeze() may be called.
>
> >
Hello,
On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
> Well, not exactly from anywhere. Just from where try_to_freeze() is called
> I suppose?
Yeap, anywhere try_to_freeze() may be called.
> Which means that if this is a user space task, it won't to a lot before dying,
>
On Tuesday, September 09, 2014 07:22:53 AM Tejun Heo wrote:
> On Mon, Sep 08, 2014 at 11:53:34PM +0200, Rafael J. Wysocki wrote:
> > But please tell me this: If TIF_MEMDIE is set and we thaw the process,
> > can it do *anything* before dying or will it die immediately?
>
> The task could be in
On Mon, Sep 08, 2014 at 11:53:34PM +0200, Rafael J. Wysocki wrote:
> But please tell me this: If TIF_MEMDIE is set and we thaw the process,
> can it do *anything* before dying or will it die immediately?
The task could be in freezer from anywhere and there's no limit in
what the task may do
On Monday, September 08, 2014 01:58:30 PM Cong Wang wrote:
> On Mon, Sep 8, 2014 at 1:54 PM, Rafael J. Wysocki wrote:
> > On Monday, September 08, 2014 10:40:17 AM Cong Wang wrote:
> >>
> >> We asked you to comment on either if this patch is safe for PM freeze
> >> if we don't have the
On Mon, Sep 8, 2014 at 1:54 PM, Rafael J. Wysocki wrote:
> On Monday, September 08, 2014 10:40:17 AM Cong Wang wrote:
>>
>> We asked you to comment on either if this patch is safe for PM freeze
>> if we don't have the cgroup_freezing() check, or if it is not safe why (so
>> that
>> I can put it
On Monday, September 08, 2014 10:40:17 AM Cong Wang wrote:
> On Fri, Sep 5, 2014 at 4:32 PM, Rafael J. Wysocki wrote:
> > On Saturday, September 06, 2014 07:45:54 AM Tejun Heo wrote:
> >> Hello,
> >>
> >> On Fri, Sep 05, 2014 at 11:12:24AM -0700, Cong Wang wrote:
> >> > > Rafael, can you please
On Fri, Sep 5, 2014 at 4:32 PM, Rafael J. Wysocki wrote:
> On Saturday, September 06, 2014 07:45:54 AM Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Sep 05, 2014 at 11:12:24AM -0700, Cong Wang wrote:
>> > > Rafael, can you please help?
>> >
>> > Rafael is known not responsive at least for this topic.
On Fri, Sep 5, 2014 at 4:32 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Saturday, September 06, 2014 07:45:54 AM Tejun Heo wrote:
Hello,
On Fri, Sep 05, 2014 at 11:12:24AM -0700, Cong Wang wrote:
Rafael, can you please help?
Rafael is known not responsive at least for this topic.
On Monday, September 08, 2014 10:40:17 AM Cong Wang wrote:
On Fri, Sep 5, 2014 at 4:32 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Saturday, September 06, 2014 07:45:54 AM Tejun Heo wrote:
Hello,
On Fri, Sep 05, 2014 at 11:12:24AM -0700, Cong Wang wrote:
Rafael, can you please
On Mon, Sep 8, 2014 at 1:54 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, September 08, 2014 10:40:17 AM Cong Wang wrote:
We asked you to comment on either if this patch is safe for PM freeze
if we don't have the cgroup_freezing() check, or if it is not safe why (so
that
I can
On Monday, September 08, 2014 01:58:30 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 1:54 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, September 08, 2014 10:40:17 AM Cong Wang wrote:
We asked you to comment on either if this patch is safe for PM freeze
if we don't have the
On Mon, Sep 08, 2014 at 11:53:34PM +0200, Rafael J. Wysocki wrote:
But please tell me this: If TIF_MEMDIE is set and we thaw the process,
can it do *anything* before dying or will it die immediately?
The task could be in freezer from anywhere and there's no limit in
what the task may do before
On Tuesday, September 09, 2014 07:22:53 AM Tejun Heo wrote:
On Mon, Sep 08, 2014 at 11:53:34PM +0200, Rafael J. Wysocki wrote:
But please tell me this: If TIF_MEMDIE is set and we thaw the process,
can it do *anything* before dying or will it die immediately?
The task could be in freezer
Hello,
On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
Well, not exactly from anywhere. Just from where try_to_freeze() is called
I suppose?
Yeap, anywhere try_to_freeze() may be called.
Which means that if this is a user space task, it won't to a lot before dying,
will
On Tuesday, September 09, 2014 07:50:12 AM Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
Well, not exactly from anywhere. Just from where try_to_freeze() is called
I suppose?
Yeap, anywhere try_to_freeze() may be called.
Which means that
On Mon, Sep 8, 2014 at 4:15 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, September 09, 2014 07:50:12 AM Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
Well, not exactly from anywhere. Just from where try_to_freeze() is called
I
On Monday, September 08, 2014 04:00:41 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:15 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, September 09, 2014 07:50:12 AM Tejun Heo wrote:
Hello,
On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
Well, not exactly
On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
The reason why it matters for the suspend-time freezing is that we freeze
tasks
to take them out of the picture entirely until they are thawed. Therefore we
can't allow them to go back to the picture just for a
On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
The reason why it matters for the suspend-time freezing is that we freeze
tasks
to take them out of the picture entirely until they are thawed.
On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
The reason why it matters for the suspend-time freezing is that we freeze
On Monday, September 08, 2014 04:29:24 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki r...@rjwysocki.net
wrote:
The reason why
On Saturday, September 06, 2014 07:45:54 AM Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 05, 2014 at 11:12:24AM -0700, Cong Wang wrote:
> > > Rafael, can you please help?
> >
> > Rafael is known not responsive at least for this topic. :)
>
> :(
Well, am I?
I haven't commented patches in this
Hello,
On Fri, Sep 05, 2014 at 11:12:24AM -0700, Cong Wang wrote:
> > Rafael, can you please help?
>
> Rafael is known not responsive at least for this topic. :)
:(
> > Shouldn't the primary goal of the comment be explaining why we need
> > TIF_MEMDIE check there at all anyway? The deadlock
1 - 100 of 116 matches
Mail list logo
