On 2015/8/24 12:56, Jaegeuk Kim wrote:
> Hi Zhang,
>
> On Mon, Aug 24, 2015 at 11:39:55AM +0800, Zhang Zhen wrote:
>> __add_ino_entry is looping around the allocation request and minics
>> __GFP_NOFAIL behavior without any allocation fallback strategy.
>> Here remove the open coded loop and replace it with __GFP_NOFAIL.
>>
>> Signed-off-by: Zhang Zhen <zhenzhang.zh...@huawei.com>
>> ---
>> fs/f2fs/checkpoint.c | 7 +------
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index b70bbe1..d62363b 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -337,12 +337,7 @@ retry:
>>
>> e = radix_tree_lookup(&im->ino_root, ino);
>> if (!e) {
>> - e = kmem_cache_alloc(ino_entry_slab, GFP_ATOMIC);
>> - if (!e) {
>> - spin_unlock(&im->ino_lock);
>> - radix_tree_preload_end();
>> - goto retry;
>> - }
>> + e = kmem_cache_alloc(ino_entry_slab, GFP_ATOMIC|__GFP_NOFAIL);
>
> I submitted a patch to replace GFP_ATOMIC with GFP_NOFS.
> We can avoid to use GFP_ATOMIC here, right?
>
Yes, i think so.
> Thanks,
>
>> if (radix_tree_insert(&im->ino_root, ino, e)) {
>> spin_unlock(&im->ino_lock);
>> kmem_cache_free(ino_entry_slab, e);
>> --
>> 1.9.1
>>
>>
>> .
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Linux-f2fs-devel mailing list
>> Linux-f2fs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
>
------------------------------------------------------------------------------
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
