Michal Hocko wrote:
> On Tue 03-07-18 00:08:05, Greg Thelen wrote:
>> Michal Hocko wrote:
>>
>> > On Fri 29-06-18 11:59:04, Greg Thelen wrote:
>> >> Michal Hocko wrote:
>> >>
>> >> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
>> >> >> Michal Hocko wrote:
>> >> > [...]
>> >> >> > +if
Michal Hocko wrote:
> On Tue 03-07-18 00:08:05, Greg Thelen wrote:
>> Michal Hocko wrote:
>>
>> > On Fri 29-06-18 11:59:04, Greg Thelen wrote:
>> >> Michal Hocko wrote:
>> >>
>> >> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
>> >> >> Michal Hocko wrote:
>> >> > [...]
>> >> >> > +if
On Tue 03-07-18 00:08:05, Greg Thelen wrote:
> Michal Hocko wrote:
>
> > On Fri 29-06-18 11:59:04, Greg Thelen wrote:
> >> Michal Hocko wrote:
> >>
> >> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> >> >> Michal Hocko wrote:
> >> > [...]
> >> >> > + if (mem_cgroup_out_of_memory(memcg,
On Tue 03-07-18 00:08:05, Greg Thelen wrote:
> Michal Hocko wrote:
>
> > On Fri 29-06-18 11:59:04, Greg Thelen wrote:
> >> Michal Hocko wrote:
> >>
> >> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> >> >> Michal Hocko wrote:
> >> > [...]
> >> >> > + if (mem_cgroup_out_of_memory(memcg,
Michal Hocko wrote:
> On Fri 29-06-18 11:59:04, Greg Thelen wrote:
>> Michal Hocko wrote:
>>
>> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
>> >> Michal Hocko wrote:
>> > [...]
>> >> > + if (mem_cgroup_out_of_memory(memcg, mask, order))
>> >> > + return OOM_SUCCESS;
>>
Michal Hocko wrote:
> On Fri 29-06-18 11:59:04, Greg Thelen wrote:
>> Michal Hocko wrote:
>>
>> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
>> >> Michal Hocko wrote:
>> > [...]
>> >> > + if (mem_cgroup_out_of_memory(memcg, mask, order))
>> >> > + return OOM_SUCCESS;
>>
On Fri 29-06-18 11:59:04, Greg Thelen wrote:
> Michal Hocko wrote:
>
> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> >> Michal Hocko wrote:
> > [...]
> >> > +if (mem_cgroup_out_of_memory(memcg, mask, order))
> >> > +return OOM_SUCCESS;
> >> > +
> >> > +
On Fri 29-06-18 11:59:04, Greg Thelen wrote:
> Michal Hocko wrote:
>
> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> >> Michal Hocko wrote:
> > [...]
> >> > +if (mem_cgroup_out_of_memory(memcg, mask, order))
> >> > +return OOM_SUCCESS;
> >> > +
> >> > +
Michal Hocko wrote:
> On Thu 28-06-18 16:19:07, Greg Thelen wrote:
>> Michal Hocko wrote:
> [...]
>> > + if (mem_cgroup_out_of_memory(memcg, mask, order))
>> > + return OOM_SUCCESS;
>> > +
>> > + WARN(1,"Memory cgroup charge failed because of no reclaimable memory! "
>> > +
Michal Hocko wrote:
> On Thu 28-06-18 16:19:07, Greg Thelen wrote:
>> Michal Hocko wrote:
> [...]
>> > + if (mem_cgroup_out_of_memory(memcg, mask, order))
>> > + return OOM_SUCCESS;
>> > +
>> > + WARN(1,"Memory cgroup charge failed because of no reclaimable memory! "
>> > +
On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> Michal Hocko wrote:
[...]
> > + if (mem_cgroup_out_of_memory(memcg, mask, order))
> > + return OOM_SUCCESS;
> > +
> > + WARN(1,"Memory cgroup charge failed because of no reclaimable memory! "
> > + "This looks like a
On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> Michal Hocko wrote:
[...]
> > + if (mem_cgroup_out_of_memory(memcg, mask, order))
> > + return OOM_SUCCESS;
> > +
> > + WARN(1,"Memory cgroup charge failed because of no reclaimable memory! "
> > + "This looks like a
Michal Hocko wrote:
> From: Michal Hocko
>
> 3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
> has changed the ENOMEM semantic of memcg charges. Rather than invoking
> the oom killer from the charging context it delays the oom killer to the
> page fault path
Michal Hocko wrote:
> From: Michal Hocko
>
> 3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
> has changed the ENOMEM semantic of memcg charges. Rather than invoking
> the oom killer from the charging context it delays the oom killer to the
> page fault path
From: Michal Hocko
3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
has changed the ENOMEM semantic of memcg charges. Rather than invoking
the oom killer from the charging context it delays the oom killer to the
page fault path (pagefault_out_of_memory). This in turn
From: Michal Hocko
3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
has changed the ENOMEM semantic of memcg charges. Rather than invoking
the oom killer from the charging context it delays the oom killer to the
page fault path (pagefault_out_of_memory). This in turn
On Thu 21-06-18 10:37:51, Johannes Weiner wrote:
> On Thu, Jun 21, 2018 at 10:09:27AM +0200, Michal Hocko wrote:
> > @@ -496,14 +496,14 @@ void mem_cgroup_print_oom_info(struct mem_cgroup
> > *memcg,
> >
> > static inline void mem_cgroup_oom_enable(void)
> > {
> > -
On Thu 21-06-18 10:37:51, Johannes Weiner wrote:
> On Thu, Jun 21, 2018 at 10:09:27AM +0200, Michal Hocko wrote:
> > @@ -496,14 +496,14 @@ void mem_cgroup_print_oom_info(struct mem_cgroup
> > *memcg,
> >
> > static inline void mem_cgroup_oom_enable(void)
> > {
> > -
On Thu, Jun 21, 2018 at 10:09:27AM +0200, Michal Hocko wrote:
> @@ -496,14 +496,14 @@ void mem_cgroup_print_oom_info(struct mem_cgroup *memcg,
>
> static inline void mem_cgroup_oom_enable(void)
> {
> - WARN_ON(current->memcg_may_oom);
> - current->memcg_may_oom = 1;
> +
On Thu, Jun 21, 2018 at 10:09:27AM +0200, Michal Hocko wrote:
> @@ -496,14 +496,14 @@ void mem_cgroup_print_oom_info(struct mem_cgroup *memcg,
>
> static inline void mem_cgroup_oom_enable(void)
> {
> - WARN_ON(current->memcg_may_oom);
> - current->memcg_may_oom = 1;
> +
mcg, oom: move out_of_memory back to the charge path
3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
has changed the ENOMEM semantic of memcg charges. Rather than invoking
the oom killer from the charging context it delays the oom killer to the
pa
mcg, oom: move out_of_memory back to the charge path
3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
has changed the ENOMEM semantic of memcg charges. Rather than invoking
the oom killer from the charging context it delays the oom killer to the
pa
On Wed 20-06-18 15:38:36, Johannes Weiner wrote:
> On Wed, Jun 20, 2018 at 05:31:48PM +0200, Michal Hocko wrote:
> > * Please note that mem_cgroup_oom_synchronize might fail to find a
> > * victim and then we have rely on mem_cgroup_oom_synchronize otherwise
> > * we would fall back
On Wed 20-06-18 15:38:36, Johannes Weiner wrote:
> On Wed, Jun 20, 2018 at 05:31:48PM +0200, Michal Hocko wrote:
> > * Please note that mem_cgroup_oom_synchronize might fail to find a
> > * victim and then we have rely on mem_cgroup_oom_synchronize otherwise
> > * we would fall back
On Wed, Jun 20, 2018 at 05:31:48PM +0200, Michal Hocko wrote:
>* Please note that mem_cgroup_oom_synchronize might fail to find a
>* victim and then we have rely on mem_cgroup_oom_synchronize otherwise
>* we would fall back to the global oom killer in
>
On Wed, Jun 20, 2018 at 05:31:48PM +0200, Michal Hocko wrote:
>* Please note that mem_cgroup_oom_synchronize might fail to find a
>* victim and then we have rely on mem_cgroup_oom_synchronize otherwise
>* we would fall back to the global oom killer in
>
On Wed, Jun 20, 2018 at 05:31:48PM +0200, Michal Hocko wrote:
> This?
> if (order > PAGE_ALLOC_COSTLY_ORDER)
> return OOM_SKIPPED;
>
> /*
>* We are in the middle of the charge context here, so we
>* don't want to block when potentially sitting on a
On Wed, Jun 20, 2018 at 05:31:48PM +0200, Michal Hocko wrote:
> This?
> if (order > PAGE_ALLOC_COSTLY_ORDER)
> return OOM_SKIPPED;
>
> /*
>* We are in the middle of the charge context here, so we
>* don't want to block when potentially sitting on a
On Wed 20-06-18 17:31:48, Michal Hocko wrote:
> On Wed 20-06-18 11:18:12, Johannes Weiner wrote:
[...]
> > 1) Why warn for kernel allocations, but not userspace ones? This
> > should have a comment at least.
>
> I am not sure I understand. We do warn for all allocations types of
>
On Wed 20-06-18 17:31:48, Michal Hocko wrote:
> On Wed 20-06-18 11:18:12, Johannes Weiner wrote:
[...]
> > 1) Why warn for kernel allocations, but not userspace ones? This
> > should have a comment at least.
>
> I am not sure I understand. We do warn for all allocations types of
>
On Wed 20-06-18 11:18:12, Johannes Weiner wrote:
> On Wed, Jun 20, 2018 at 12:37:36PM +0200, Michal Hocko wrote:
[...]
> > -static void mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order)
> > +enum oom_status {
> > + OOM_SUCCESS,
> > + OOM_FAILED,
> > + OOM_ASYNC,
> > +
On Wed 20-06-18 11:18:12, Johannes Weiner wrote:
> On Wed, Jun 20, 2018 at 12:37:36PM +0200, Michal Hocko wrote:
[...]
> > -static void mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order)
> > +enum oom_status {
> > + OOM_SUCCESS,
> > + OOM_FAILED,
> > + OOM_ASYNC,
> > +
On Wed, Jun 20, 2018 at 12:37:36PM +0200, Michal Hocko wrote:
> From: Michal Hocko
>
> 3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
> has changed the ENOMEM semantic of memcg charges. Rather than invoking
> the oom killer from the charging context it delays the oom
On Wed, Jun 20, 2018 at 12:37:36PM +0200, Michal Hocko wrote:
> From: Michal Hocko
>
> 3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
> has changed the ENOMEM semantic of memcg charges. Rather than invoking
> the oom killer from the charging context it delays the oom
From: Michal Hocko
3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
has changed the ENOMEM semantic of memcg charges. Rather than invoking
the oom killer from the charging context it delays the oom killer to the
page fault path (pagefault_out_of_memory). This in turn
From: Michal Hocko
3812c8c8f395 ("mm: memcg: do not trap chargers with full callstack on OOM")
has changed the ENOMEM semantic of memcg charges. Rather than invoking
the oom killer from the charging context it delays the oom killer to the
page fault path (pagefault_out_of_memory). This in turn
36 matches
Mail list logo
