From: Nikolay Borisov <kernel@kyup.com>
To: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] mm: remove __GFP_NOFAIL is deprecated comment
Date: Thu, 25 Feb 2016 13:36:11 +0200 [thread overview]
Message-ID: <56CEE72B.5040009@kyup.com> (raw)
In-Reply-To: <1456397002-27172-1-git-send-email-mhocko@kernel.org>
On 02/25/2016 12:43 PM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> 647757197cd3 ("mm: clarify __GFP_NOFAIL deprecation status") was
> incomplete and didn't remove the comment about __GFP_NOFAIL being
> deprecated in buffered_rmqueue. Let's get rid of this leftover
> but keep the WARN_ON_ONCE for order > 1 because we should really
> discourage from using __GFP_NOFAIL with higher order allocations
> because those are just too subtle.
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> Hi,
> this popped out when discussing another patch http://lkml.kernel.org/r/56CEC568.6080809@kyup.com
> so I think it is worth removing the comment.
>
> mm/page_alloc.c | 18 +++++-------------
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 1993894b4219..109d975a7172 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2347,19 +2347,11 @@ struct page *buffered_rmqueue(struct zone *preferred_zone,
> list_del(&page->lru);
> pcp->count--;
> } else {
> - if (unlikely(gfp_flags & __GFP_NOFAIL)) {
> - /*
> - * __GFP_NOFAIL is not to be used in new code.
> - *
> - * All __GFP_NOFAIL callers should be fixed so that they
> - * properly detect and handle allocation failures.
> - *
> - * We most definitely don't want callers attempting to
> - * allocate greater than order-1 page units with
> - * __GFP_NOFAIL.
> - */
> - WARN_ON_ONCE(order > 1);
> - }
> + /*
> + * We most definitely don't want callers attempting to
> + * allocate greater than order-1 page units with __GFP_NOFAIL.
> + */
> + WARN_ON_ONCE(unlikely(gfp_flags & __GFP_NOFAIL) && (order > 1));
WARN_ON_ONCE already includes an unlikely in its definition:
http://lxr.free-electrons.com/source/include/asm-generic/bug.h#L109
> spin_lock_irqsave(&zone->lock, flags);
>
> page = NULL;
>
Reviewed-by: Nikolay Borisov <kernel@kyup.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Borisov <kernel@kyup.com>
To: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] mm: remove __GFP_NOFAIL is deprecated comment
Date: Thu, 25 Feb 2016 13:36:11 +0200 [thread overview]
Message-ID: <56CEE72B.5040009@kyup.com> (raw)
In-Reply-To: <1456397002-27172-1-git-send-email-mhocko@kernel.org>
On 02/25/2016 12:43 PM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> 647757197cd3 ("mm: clarify __GFP_NOFAIL deprecation status") was
> incomplete and didn't remove the comment about __GFP_NOFAIL being
> deprecated in buffered_rmqueue. Let's get rid of this leftover
> but keep the WARN_ON_ONCE for order > 1 because we should really
> discourage from using __GFP_NOFAIL with higher order allocations
> because those are just too subtle.
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> Hi,
> this popped out when discussing another patch http://lkml.kernel.org/r/56CEC568.6080809@kyup.com
> so I think it is worth removing the comment.
>
> mm/page_alloc.c | 18 +++++-------------
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 1993894b4219..109d975a7172 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2347,19 +2347,11 @@ struct page *buffered_rmqueue(struct zone *preferred_zone,
> list_del(&page->lru);
> pcp->count--;
> } else {
> - if (unlikely(gfp_flags & __GFP_NOFAIL)) {
> - /*
> - * __GFP_NOFAIL is not to be used in new code.
> - *
> - * All __GFP_NOFAIL callers should be fixed so that they
> - * properly detect and handle allocation failures.
> - *
> - * We most definitely don't want callers attempting to
> - * allocate greater than order-1 page units with
> - * __GFP_NOFAIL.
> - */
> - WARN_ON_ONCE(order > 1);
> - }
> + /*
> + * We most definitely don't want callers attempting to
> + * allocate greater than order-1 page units with __GFP_NOFAIL.
> + */
> + WARN_ON_ONCE(unlikely(gfp_flags & __GFP_NOFAIL) && (order > 1));
WARN_ON_ONCE already includes an unlikely in its definition:
http://lxr.free-electrons.com/source/include/asm-generic/bug.h#L109
> spin_lock_irqsave(&zone->lock, flags);
>
> page = NULL;
>
Reviewed-by: Nikolay Borisov <kernel@kyup.com>
next prev parent reply other threads:[~2016-02-25 11:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 10:43 [PATCH] mm: remove __GFP_NOFAIL is deprecated comment Michal Hocko
2016-02-25 10:43 ` Michal Hocko
2016-02-25 11:36 ` Nikolay Borisov [this message]
2016-02-25 11:36 ` Nikolay Borisov
2016-02-25 13:48 ` Michal Hocko
2016-02-25 13:48 ` Michal Hocko
2016-03-07 14:57 ` Vlastimil Babka
2016-03-07 14:57 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CEE72B.5040009@kyup.com \
--to=kernel@kyup.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.