Re: [PATCH 1/3] f2fs: avoid using __GFP_NOFAIL

2017-11-06 Thread Chao Yu
On 2017/11/7 0:23, Michal Hocko wrote: > On Tue 07-11-17 00:08:25, Chao Yu wrote: > [...] >> BTW, I notice the comments of __GFP_NOFAIL, what does this mean? >> * Using this flag for costly allocations is _highly_ discouraged. > > This means that using __GFP_NOFAIL for high order allocations >

Re: [PATCH 1/3] f2fs: avoid using __GFP_NOFAIL

2017-11-06 Thread Michal Hocko
On Tue 07-11-17 00:08:25, Chao Yu wrote: [...] > BTW, I notice the comments of __GFP_NOFAIL, what does this mean? > * Using this flag for costly allocations is _highly_ discouraged. This means that using __GFP_NOFAIL for high order allocations (especially those with order > PAGE_ALLOC_COSTLY_OR

Re: [PATCH 1/3] f2fs: avoid using __GFP_NOFAIL

2017-11-06 Thread Chao Yu
Hi Michal, On 2017/11/6 22:08, Michal Hocko wrote: > On Sun 05-11-17 21:53:28, Chao Yu wrote: >> From: Chao Yu >> >> We will keep __add_ino_entry success all the time, for ENOMEM failure >> case, we have already handled it with an opened loop code, so we don't >> have to use redundant __GFP_NOFAI

Re: [PATCH 1/3] f2fs: avoid using __GFP_NOFAIL

2017-11-06 Thread Michal Hocko
On Sun 05-11-17 21:53:28, Chao Yu wrote: > From: Chao Yu > > We will keep __add_ino_entry success all the time, for ENOMEM failure > case, we have already handled it with an opened loop code, so we don't > have to use redundant __GFP_NOFAIL in radix_tree_preload, remove it. Why do you think an o

[PATCH 1/3] f2fs: avoid using __GFP_NOFAIL

2017-11-05 Thread Chao Yu
From: Chao Yu We will keep __add_ino_entry success all the time, for ENOMEM failure case, we have already handled it with an opened loop code, so we don't have to use redundant __GFP_NOFAIL in radix_tree_preload, remove it. Signed-off-by: Chao Yu --- fs/f2fs/checkpoint.c | 10 +++--- 1 fil