On Mon, Aug 11, 2014 at 6:18 AM, Michal Hocko wrote:
>
> OK, so the system/memcg is still OOM and a new allocation/charge
> would trigger killer again, right? Then oom_scan_process_thread sees
> TIF_MEMDIE frozen task and thaw it so it can go away and die. So this
> shouldn't be a permanent state.
On Sat, Aug 9, 2014 at 1:55 AM, David Rientjes wrote:
> On Fri, 8 Aug 2014, Cong Wang wrote:
>
>> diff --git a/kernel/freezer.c b/kernel/freezer.c
>> index aa6a8aa..c6d189d 100644
>> --- a/kernel/freezer.c
>> +++ b/kernel/freezer.c
>> @@ -68,7 +68,9 @@ bool __refrigerator(bool check_kthr_stop)
>>
On Fri 08-08-14 17:46:38, 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 oom
> B=oom_scan_process_thread()
>
On Fri, 8 Aug 2014, Cong Wang wrote:
> diff --git a/kernel/freezer.c b/kernel/freezer.c
> index aa6a8aa..c6d189d 100644
> --- a/kernel/freezer.c
> +++ b/kernel/freezer.c
> @@ -68,7 +68,9 @@ bool __refrigerator(bool check_kthr_stop)
> spin_lock_irq(&freezer_lock);
> curr
On Fri, Aug 8, 2014 at 7:00 PM, Kyungmin Park wrote:
>
> Similar patch is posted and discussed but no conclusion.
> http://marc.info/?t=13769976944&r=1&w=1
>
I noticed this thread before sending my patch. I don't think
we are trying to solve the same problem:
a) I only care OOM kill, not oth
On Sat, Aug 9, 2014 at 9:46 AM, 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 oom
> B=oom_scan_process_thread()
>
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 oom
B=oom_scan_process_thread()
cgroup_freezer_freeze(B)
7 matches
Mail list logo
