From: Michal Nazarewicz <mina86@mina86.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: "Robin H. Johnson" <robbat2@orbis-terrarum.net>,
linux-kernel@vger.kernel.org, robbat2@gentoo.org,
linux-mm@kvack.org
Subject: Re: PROBLEM-PERSISTS: dmesg spam: alloc_contig_range: [XX, YY) PFNs busy
Date: Thu, 01 Dec 2016 02:39:35 +0100 [thread overview]
Message-ID: <xa1td1hcwhpk.fsf@mina86.com> (raw)
In-Reply-To: <robbat2-20161130T195244-998539995Z@orbis-terrarum.net>
On Wed, Nov 30 2016, Robin H. Johnson wrote:
> (I'm going to respond directly to this email with the stack trace.)
>
> On Wed, Nov 30, 2016 at 02:28:49PM +0100, Michal Hocko wrote:
>> > On the other hand, if this didn’t happen and now happens all the time,
>> > this indicates a regression in CMA’s capability to allocate pages so
>> > just rate limiting the output would hide the potential actual issue.
>>
>> Or there might be just a much larger demand on those large blocks, no?
>> But seriously, dumping those message again and again into the low (see
>> the 2.5_GB_/h to the log is just insane. So there really should be some
>> throttling.
>>
>> Does the following help you Robin. At least to not get swamped by those
>> message.
> Here's what I whipped up based on that, to ensure that dump_stack got
> rate-limited at the same pass as PFNs-busy. It dropped the dmesg spew to
> ~25MB/hour (and is suppressing ~43 entries/second right now).
>
> commit 6ad4037e18ec2199f8755274d8a745a9904241a1
> Author: Robin H. Johnson <robbat2@gentoo.org>
> Date: Wed Nov 30 10:32:57 2016 -0800
>
> mm: ratelimit & trace PFNs busy.
>
> Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6de9440e3ae2..3c28ec3d18f8 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7289,8 +7289,15 @@ int alloc_contig_range(unsigned long start, unsigned long end,
>
> /* Make sure the range is really isolated. */
> if (test_pages_isolated(outer_start, end, false)) {
> - pr_info("%s: [%lx, %lx) PFNs busy\n",
> - __func__, outer_start, end);
> + static DEFINE_RATELIMIT_STATE(ratelimit_pfn_busy,
> + DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
> + if (__ratelimit(&ratelimit_pfn_busy)) {
> + pr_info("%s: [%lx, %lx) PFNs busy\n",
> + __func__, outer_start, end);
I’m thinking out loud here, but maybe it would be useful to include
a count of how many times this message has been suppressed?
> + dump_stack();
Perhaps do it only if CMA_DEBUG?
+ if (IS_ENABLED(CONFIG_CMA_DEBUG))
+ dump_stack();
> + }
> +
> ret = -EBUSY;
> goto done;
> }
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
> E-Mail : robbat2@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
WARNING: multiple messages have this Message-ID (diff)
From: Michal Nazarewicz <mina86@mina86.com>
To: "Robin H. Johnson" <robbat2@gentoo.org>,
Michal Hocko <mhocko@kernel.org>
Cc: "Robin H. Johnson" <robbat2@orbis-terrarum.net>,
linux-kernel@vger.kernel.org, robbat2@gentoo.org,
linux-mm@kvack.org
Subject: Re: PROBLEM-PERSISTS: dmesg spam: alloc_contig_range: [XX, YY) PFNs busy
Date: Thu, 01 Dec 2016 02:39:35 +0100 [thread overview]
Message-ID: <xa1td1hcwhpk.fsf@mina86.com> (raw)
In-Reply-To: <robbat2-20161130T195244-998539995Z@orbis-terrarum.net>
On Wed, Nov 30 2016, Robin H. Johnson wrote:
> (I'm going to respond directly to this email with the stack trace.)
>
> On Wed, Nov 30, 2016 at 02:28:49PM +0100, Michal Hocko wrote:
>> > On the other hand, if this didn’t happen and now happens all the time,
>> > this indicates a regression in CMA’s capability to allocate pages so
>> > just rate limiting the output would hide the potential actual issue.
>>
>> Or there might be just a much larger demand on those large blocks, no?
>> But seriously, dumping those message again and again into the low (see
>> the 2.5_GB_/h to the log is just insane. So there really should be some
>> throttling.
>>
>> Does the following help you Robin. At least to not get swamped by those
>> message.
> Here's what I whipped up based on that, to ensure that dump_stack got
> rate-limited at the same pass as PFNs-busy. It dropped the dmesg spew to
> ~25MB/hour (and is suppressing ~43 entries/second right now).
>
> commit 6ad4037e18ec2199f8755274d8a745a9904241a1
> Author: Robin H. Johnson <robbat2@gentoo.org>
> Date: Wed Nov 30 10:32:57 2016 -0800
>
> mm: ratelimit & trace PFNs busy.
>
> Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6de9440e3ae2..3c28ec3d18f8 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7289,8 +7289,15 @@ int alloc_contig_range(unsigned long start, unsigned long end,
>
> /* Make sure the range is really isolated. */
> if (test_pages_isolated(outer_start, end, false)) {
> - pr_info("%s: [%lx, %lx) PFNs busy\n",
> - __func__, outer_start, end);
> + static DEFINE_RATELIMIT_STATE(ratelimit_pfn_busy,
> + DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
> + if (__ratelimit(&ratelimit_pfn_busy)) {
> + pr_info("%s: [%lx, %lx) PFNs busy\n",
> + __func__, outer_start, end);
I’m thinking out loud here, but maybe it would be useful to include
a count of how many times this message has been suppressed?
> + dump_stack();
Perhaps do it only if CMA_DEBUG?
+ if (IS_ENABLED(CONFIG_CMA_DEBUG))
+ dump_stack();
> + }
> +
> ret = -EBUSY;
> goto done;
> }
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
> E-Mail : robbat2@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
next prev parent reply other threads:[~2016-12-01 1:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 22:43 PROBLEM-PERSISTS: dmesg spam: alloc_contig_range: [XX, YY) PFNs busy Robin H. Johnson
2016-11-30 9:22 ` Michal Hocko
2016-11-30 13:08 ` Michal Nazarewicz
2016-11-30 13:28 ` Michal Hocko
2016-11-30 19:58 ` Robin H. Johnson
2016-11-30 20:19 ` drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy Robin H. Johnson
2016-11-30 21:24 ` Vlastimil Babka
2016-11-30 21:24 ` Vlastimil Babka
2016-12-01 6:21 ` Robin H. Johnson
2016-12-01 7:38 ` Vlastimil Babka
2016-12-01 7:38 ` Vlastimil Babka
2016-12-01 7:58 ` Robin H. Johnson
2016-12-01 7:58 ` Robin H. Johnson
2016-12-01 7:15 ` Michal Hocko
2016-12-01 7:15 ` Michal Hocko
2016-12-01 7:21 ` Michal Hocko
2016-12-01 7:21 ` Michal Hocko
2016-12-01 7:43 ` Vlastimil Babka
2016-12-01 7:43 ` Vlastimil Babka
2016-12-01 14:11 ` Michal Hocko
2016-12-01 14:11 ` Michal Hocko
2016-12-01 16:03 ` Michal Nazarewicz
2016-12-01 16:03 ` Michal Nazarewicz
2016-12-01 16:11 ` Michal Hocko
2016-12-01 16:11 ` Michal Hocko
2016-12-01 21:02 ` Michal Nazarewicz
2016-12-01 21:02 ` Michal Nazarewicz
2016-12-02 6:36 ` Vlastimil Babka
2016-12-02 6:36 ` Vlastimil Babka
2016-12-02 6:36 ` Vlastimil Babka
2016-12-02 10:26 ` Lucas Stach
2016-12-02 10:26 ` Lucas Stach
2016-12-02 15:17 ` Jerome Glisse
2016-12-02 15:17 ` Jerome Glisse
2016-12-02 15:17 ` Jerome Glisse
2016-12-01 1:39 ` Michal Nazarewicz [this message]
2016-12-01 1:39 ` PROBLEM-PERSISTS: dmesg spam: alloc_contig_range: [XX, YY) PFNs busy Michal Nazarewicz
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=xa1td1hcwhpk.fsf@mina86.com \
--to=mina86@mina86.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=robbat2@gentoo.org \
--cc=robbat2@orbis-terrarum.net \
/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.