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-kernel@vger.kernel.org>,
"linux-mm@kvack.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: Thu, 27 Dec 2018 17:50:55 +0100 [thread overview]
Message-ID: <20181227165055.GN16738@dhcp22.suse.cz> (raw)
In-Reply-To: <12c71c7a-7896-df73-7ab4-eab5b6fc1fb0@virtuozzo.com>
On Thu 27-12-18 16:05:18, Konstantin Khorenko wrote:
> On 12/26/2018 11:40 AM, Michal Hocko wrote:
> > 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).
>
> Thank you, will add in the next version of the patch alltogether
> with other changes if any.
>
> > 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?
>
> LOCKDEP makes structures big, so if we see a high order allocation warning
> on a debug kernel with lockdep, it does not give us a lot - lockdep enabled
> kernel performance is not our target.
> i can remove !LOCKDEP dependence here, but then need to adjust default
> warning level i think, or logs will be spammed.
OK, I see but this just points to how this is not really a suitable
solution for the problem you are looking for.
> >> +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?
>
> Well, my idea was to really shut up the warning after some number of messages
> (if a node is in production and its uptime, say, a year, i don't want to see
> many warnings in logs, first several is enough - let's fix them first).
OK, but it is quite likely that the system is perfectly healthy and
unfragmented after fresh boot when doing a large order allocations is
perfectly fine. Note that it is smaller order allocations that generate
fragmentation in general.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-12-27 16:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-25 15:39 [RFC PATCH 0/1] mm: add a warning about high order allocations Konstantin Khorenko
2018-12-25 15:39 ` [PATCH 1/1] mm/page_alloc: " Konstantin Khorenko
2018-12-26 8:40 ` Michal Hocko
2018-12-26 11:53 ` Michal Hocko
2018-12-27 16:05 ` Konstantin Khorenko
2018-12-27 16:50 ` Michal Hocko [this message]
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=20181227165055.GN16738@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;
as well as URLs for NNTP newsgroup(s).