On Wed, 3 Sep 2014 13:54:54 +0800 Junxiao Bi <junxiao.bi@xxxxxxxxxx> wrote:
> commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O during memory allocation")
> introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory allocation, __GFP_IO is cleared
> when this flag is set, but __GFP_FS implies __GFP_IO, it should also be cleared. Or it may still
> run into I/O, like in superblock shrinker.
Is there an actual bug which inspired this fix? If so, please describe
it.
I don't think it's accurate to say that __GFP_FS implies __GFP_IO.
Where did that info come from?
And the superblock shrinker is a good example of why this shouldn't be
the case. The main thing that code does is to reclaim clean fs objects
without performing IO. AFAICT the proposed patch will significantly
weaken PF_MEMALLOC_NOIO allocation attempts by needlessly preventing
the kernel from reclaiming such objects?
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1936,11 +1936,13 @@ extern void thread_group_cputime_adjusted(struct task_struct *p, cputime_t *ut,
> #define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
> #define used_math() tsk_used_math(current)
>
> -/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
> +/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags
> + * __GFP_FS is also cleared as it implies __GFP_IO.
> + */
> static inline gfp_t memalloc_noio_flags(gfp_t flags)
> {
> if (unlikely(current->flags & PF_MEMALLOC_NOIO))
> - flags &= ~__GFP_IO;
> + flags &= ~(__GFP_IO | __GFP_FS);
> return flags;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
