On Wed, 4 Dec 2013, Johannes Weiner wrote:
> However, the GFP_NOFS | __GFP_NOFAIL task stuck in the page allocator
> may hold filesystem locks that could prevent a third party from
> freeing memory and/or exiting, so we can not guarantee that only the
> __GFP_NOFAIL task is getting stuck, it might
On Wed, Dec 04, 2013 at 03:34:17PM +1100, Dave Chinner wrote:
> On Tue, Dec 03, 2013 at 10:01:01PM -0500, Johannes Weiner wrote:
> > On Tue, Dec 03, 2013 at 03:40:13PM -0800, David Rientjes wrote:
> > > On Tue, 3 Dec 2013, Johannes Weiner wrote:
> > > I believe the page allocator would be susceptib
On Tue, Dec 03, 2013 at 10:01:01PM -0500, Johannes Weiner wrote:
> On Tue, Dec 03, 2013 at 03:40:13PM -0800, David Rientjes wrote:
> > On Tue, 3 Dec 2013, Johannes Weiner wrote:
> > I believe the page allocator would be susceptible to the same deadlock if
> > nothing else on the system can reclaim
On Tue, Dec 03, 2013 at 03:40:13PM -0800, David Rientjes wrote:
> On Tue, 3 Dec 2013, Johannes Weiner wrote:
>
> > > > Spin on which level? The whole point of this change was to not spin for
> > > > ever because the caller might sit on top of other locks which might
> > > > prevent somebody else t
On Tue, 3 Dec 2013, Johannes Weiner wrote:
> > > Spin on which level? The whole point of this change was to not spin for
> > > ever because the caller might sit on top of other locks which might
> > > prevent somebody else to die although it has been killed.
> >
> > See my question about the non-
On Mon, Dec 02, 2013 at 03:02:09PM -0800, David Rientjes wrote:
> On Mon, 2 Dec 2013, Michal Hocko wrote:
>
> > > > What if the callers simply cannot deal with the allocation failure?
> > > > 84235de394d97 (fs: buffer: move allocation failure loop into the
> > > > allocator) describes one such cas
On Mon, 2 Dec 2013, Michal Hocko wrote:
> > > What if the callers simply cannot deal with the allocation failure?
> > > 84235de394d97 (fs: buffer: move allocation failure loop into the
> > > allocator) describes one such case when __getblk_slow tries desperately
> > > to grow buffers relying on th
On Fri 29-11-13 15:46:16, David Rientjes wrote:
> On Thu, 28 Nov 2013, Michal Hocko wrote:
>
> > > Ok, so let's forget about GFP_KERNEL | __GFP_NOFAIL since anything doing
> > > __GFP_FS should not be holding such locks, we have some of those in the
> > > drivers code and that makes sense that t
On Thu, 28 Nov 2013, Michal Hocko wrote:
> > Ok, so let's forget about GFP_KERNEL | __GFP_NOFAIL since anything doing
> > __GFP_FS should not be holding such locks, we have some of those in the
> > drivers code and that makes sense that they are doing GFP_KERNEL.
> >
> > Focusing on the GFP_NOF
On Wed 27-11-13 15:34:24, David Rientjes wrote:
> On Wed, 27 Nov 2013, Johannes Weiner wrote:
>
> > > We don't give __GFP_NOFAIL allocations access to memory reserves in the
> > > page allocator and we do call the oom killer for them so that a process
> > > is
> > > killed so that memory is fre
On Wed, 27 Nov 2013, Johannes Weiner wrote:
> > We don't give __GFP_NOFAIL allocations access to memory reserves in the
> > page allocator and we do call the oom killer for them so that a process is
> > killed so that memory is freed. Why do we have a different policy for
> > memcg?
>
> Oh bo
On Wed, Nov 27, 2013 at 01:38:59PM -0800, David Rientjes wrote:
> On Wed, 27 Nov 2013, Johannes Weiner wrote:
>
> > > Ah, this is because of 3168ecbe1c04 ("mm: memcg: use proper memcg in
> > > limit
> > > bypass") which just bypasses all of these allocations and charges the
> > > root
> > > me
On Wed, 27 Nov 2013, Johannes Weiner wrote:
> > Ah, this is because of 3168ecbe1c04 ("mm: memcg: use proper memcg in limit
> > bypass") which just bypasses all of these allocations and charges the root
> > memcg. So if allocations want to bypass memcg isolation they just have to
> > be __GFP_N
On Tue, Nov 26, 2013 at 07:33:12PM -0800, David Rientjes wrote:
> On Tue, 26 Nov 2013, David Rientjes wrote:
>
> > On Fri, 22 Nov 2013, Johannes Weiner wrote:
> >
> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > index 13b9d0f..cc4f9cb 100644
> > > --- a/mm/memcontrol.c
> > > +++ b/mm/me
On Tue, 26 Nov 2013, David Rientjes wrote:
> On Fri, 22 Nov 2013, Johannes Weiner wrote:
>
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 13b9d0f..cc4f9cb 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -2677,6 +2677,9 @@ static int __mem_cgroup_try_charge(struct m
On Fri, 22 Nov 2013, Johannes Weiner wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 13b9d0f..cc4f9cb 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2677,6 +2677,9 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
> if (unlikely(task_in_memcg_oom(curre
16 matches
Mail list logo
