On Tue 25-10-16 11:01:42, Johannes Weiner wrote:
> On Tue, Oct 25, 2016 at 04:45:44PM +0200, Michal Hocko wrote:
> > On Tue 25-10-16 10:10:50, Johannes Weiner wrote:
> > > Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC
> > > to avoid recursing into any other form of direct re
On Tue, Oct 25, 2016 at 04:45:44PM +0200, Michal Hocko wrote:
> On Tue 25-10-16 10:10:50, Johannes Weiner wrote:
> > Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC
> > to avoid recursing into any other form of direct reclaim. Then let
> > recursive charges from PF_MEMALLOC co
2001
> From: Johannes Weiner
> Date: Mon, 24 Oct 2016 16:01:55 -0400
> Subject: [PATCH] mm: memcontrol: do not recurse in direct reclaim
>
> On 4.0, we saw a stack corruption from a page fault entering direct
> memory cgroup reclaim, calling into btrfs_releasepage(), which th
fair enough. I also added why we prefer temporarily breaching
the limit over failing the allocation. How is this?
>From 9034d2e6a21036774df9a8e021511720cf432c82 Mon Sep 17 00:00:00 2001
From: Johannes Weiner
Date: Mon, 24 Oct 2016 16:01:55 -0400
Subject: [PATCH] mm: memcontrol: do not re
On Mon 24-10-16 16:30:05, Johannes Weiner wrote:
> On 4.0, we saw a stack corruption from a page fault entering direct
> memory cgroup reclaim, calling into btrfs_releasepage(), which then
> tried to allocate an extent and recursed back into a kmem charge ad
> nauseam:
>
> [...]
> [] btrfs_release
On 4.0, we saw a stack corruption from a page fault entering direct
memory cgroup reclaim, calling into btrfs_releasepage(), which then
tried to allocate an extent and recursed back into a kmem charge ad
nauseam:
[...]
[] btrfs_releasepage+0x2c/0x30
[] try_to_release_page+0x32/0x50
[] shrink_page_
6 matches
Mail list logo
