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