[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 follow
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
>> tr
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 00:00:00
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 b
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 wa
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_thr
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
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? D
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 Micha
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
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 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 Micha
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: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 ki
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 k
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
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'
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:25
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_free
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) &&
>> cgro
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. Wysock
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 f
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
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 safe,
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
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 currentl
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 tha
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
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 there
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 th
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 o
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 a
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 fr
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 suppose?
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
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,
> wi
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 fre
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 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 cgroup_free
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 i
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 he
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 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 thre
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 po
On Fri, Sep 5, 2014 at 11:00 AM, Tejun Heo wrote:
> On Fri, Sep 05, 2014 at 09:31:50AM -0700, Cong Wang wrote:
>> On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
>> >> + /* It might not be safe to check TIF_MEMDIE for pm freeze. */
>> >
>> > This is just another representation of the followi
On Fri, Sep 05, 2014 at 09:31:50AM -0700, Cong Wang wrote:
> On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
> >> + /* It might not be safe to check TIF_MEMDIE for pm freeze. */
> >
> > This is just another representation of the following code which isn't
> > particularly useful. Wouldn't it
On Fri 05-09-14 09:43:52, Cong Wang wrote:
> On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
> >
> > Prolly should sta...@vger.kernel.org?
>
> Oh, yes. I assume the maintainer (Michal?) will send it to stable
I guess you meant Rafael.
> once it is accepted, or I can do that after it is merged.
On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
>
> Prolly should sta...@vger.kernel.org?
Oh, yes. I assume the maintainer (Michal?) will send it to stable
once it is accepted, or I can do that after it is merged.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
>> + /* It might not be safe to check TIF_MEMDIE for pm freeze. */
>
> This is just another representation of the following code which isn't
> particularly useful. Wouldn't it be better if the comment actually
> explains why this might not be s
Hello,
On Thu, Sep 04, 2014 at 03:30:41PM -0700, Cong Wang wrote:
...
> Cc: David Rientjes
> Cc: Michal Hocko
> Cc: "Rafael J. Wysocki"
> Cc: Tejun Heo
> Cc: Andrew Morton
> Acked-by: Michal Hocko
> Signed-off-by: Cong Wang
Prolly should sta...@vger.kernel.org?
> +static bool should_thaw_
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()
cgroup free
58 matches
Mail list logo
