From: Michal Hocko <mhocko@kernel.org>
To: Konstantin Khorenko <khorenko@virtuozzo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 1/1] mm/page_alloc: add a warning about high order allocations
Date: Wed, 26 Dec 2018 09:40:51 +0100 [thread overview]
Message-ID: <20181226084051.GH16738@dhcp22.suse.cz> (raw)
In-Reply-To: <20181225153927.2873-2-khorenko@virtuozzo.com>
Appart from general comments as a reply to the cover (btw. this all
should be in the changelog because this is the _why_ part of the
justification which should be _always_ part of the changelog).
On Tue 25-12-18 18:39:27, Konstantin Khorenko wrote:
[...]
> +config WARN_HIGH_ORDER
> + bool "Enable complains about high order memory allocations"
> + depends on !LOCKDEP
Why?
> + default n
> + help
> + Enables warnings on high order memory allocations. This allows to
> + determine users of large memory chunks and rework them to decrease
> + allocation latency. Note, some debug options make kernel structures
> + fat.
> +
> +config WARN_HIGH_ORDER_LEVEL
> + int "Define page order level considered as too high"
> + depends on WARN_HIGH_ORDER
> + default 3
> + help
> + Defines page order starting which the system to complain about.
> + Default is current PAGE_ALLOC_COSTLY_ORDER.
> +
> config HWPOISON_INJECT
> tristate "HWPoison pages injector"
> depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index e95b5b7c9c3d..258892adb861 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4341,6 +4341,30 @@ static inline void finalise_ac(gfp_t gfp_mask, struct alloc_context *ac)
> ac->high_zoneidx, ac->nodemask);
> }
>
> +#ifdef CONFIG_WARN_HIGH_ORDER
> +int warn_order = CONFIG_WARN_HIGH_ORDER_LEVEL;
> +
> +/*
> + * Complain if we allocate a high order page unless there is a __GFP_NOWARN
> + * flag provided.
> + *
> + * Shuts up after 32 complains.
> + */
> +static __always_inline void warn_high_order(int order, gfp_t gfp_mask)
> +{
> + static atomic_t warn_count = ATOMIC_INIT(32);
> +
> + if (order >= warn_order && !(gfp_mask & __GFP_NOWARN))
> + WARN(atomic_dec_if_positive(&warn_count) >= 0,
> + "order %d >= %d, gfp 0x%x\n",
> + order, warn_order, gfp_mask);
> +}
We do have ratelimit functionality, so why cannot you use it?
> +#else
> +static __always_inline void warn_high_order(int order, gfp_t gfp_mask)
> +{
> +}
> +#endif
> +
> /*
> * This is the 'heart' of the zoned buddy allocator.
> */
> @@ -4361,6 +4385,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
> WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
> return NULL;
> }
> + warn_high_order(order, gfp_mask);
>
> gfp_mask &= gfp_allowed_mask;
> alloc_mask = gfp_mask;
Why do you warn about all allocations in the hot path? I thought you
want to catch expensive allocations so I would assume that you would
stick that into a slow path after we are not able to allocate anything
after the first round of compaction.
Also do you want to warn about opportunistic GFP_NOWAIT allocations that
have a reasonable fallback?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-12-26 8:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-25 15:39 [RFC PATCH 0/1] mm: " Konstantin Khorenko
2018-12-25 15:39 ` [PATCH 1/1] mm/page_alloc: " Konstantin Khorenko
2018-12-26 8:40 ` Michal Hocko [this message]
2018-12-26 11:53 ` Michal Hocko
2018-12-27 16:05 ` Konstantin Khorenko
2018-12-27 16:50 ` Michal Hocko
2018-12-28 14:45 ` Konstantin Khorenko
2018-12-26 8:35 ` [RFC PATCH 0/1] mm: " Michal Hocko
2018-12-27 15:18 ` Konstantin Khorenko
2018-12-27 16:46 ` Michal Hocko
2018-12-28 14:23 ` Konstantin Khorenko
2018-12-28 19:44 ` Michal Hocko
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=20181226084051.GH16738@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=keescook@chromium.org \
--cc=khorenko@virtuozzo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox