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 )?
|