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 )? _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
