Re: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Dave Chinner wrote:
> On Sun, Sep 20, 2015 at 04:03:13PM +0900, Tetsuo Handa wrote:
> > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory() are doing
> > open-coded __GFP_NOFAIL allocations with warning messages as a canary.
> > But since small !__GFP_NOFAIL allocations retry forever inside memory
> > allocator unless TIF_MEMDIE is set, the canary does not help even if
> > allocations are stalling. Thus, this patch adds __GFP_NORETRY so that
> > we can know possibility of allocation deadlock.
> > 
> > If a patchset which makes small !__GFP_NOFAIL !__GFP_FS allocations not
> > retry inside memory allocator is merged, warning messages by
> > warn_alloc_failed() will dominate warning messages by the canary
> > because each thread calls warn_alloc_failed() for approximately
> > every 2 milliseconds. Thus, this patch also adds __GFP_NOWARN so that
> > we won't flood kernel logs by these open-coded __GFP_NOFAIL allocations.
> 
> Please, at minimum, look at the code you are modifying. __GFP_NOWARN
> is already set by both kmem_flags_convert() and xb_to_gfp(),
> precisely for this reason. Any changes to the default gfp flags we
> use need to be inside those wrappers - that's why they exist.

Indeed.

> 
> Further, xb_to_gfp() may already return just "__GFP_NORETRY |
> __GFP_NOWARN", so appending them unconditionally is clearly not the
> best approach.

I see.

> 
> Further, fundamentally changing the allocation behaviour of the
> filesystem requires some indication of the testing and
> characterisation of how the change has impacted low memory balance
> and performance of the filesystem.

Well, I don't have rich environment for evaluating how the change impacts
low memory balance and performance of the filesystem. Therefore, I cancel
this patch.

Please reply if you have comments on "[RFC 0/8] Allow GFP_NOFS allocation
to fail" patchset ( http://marc.info/?l=linux-mm&m=143876830616538 )?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>