Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757338AbcK3N3A (ORCPT ); Wed, 30 Nov 2016 08:29:00 -0500 Received: from mail-wj0-f193.google.com ([209.85.210.193]:36039 "EHLO mail-wj0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750922AbcK3N2v (ORCPT ); Wed, 30 Nov 2016 08:28:51 -0500 Date: Wed, 30 Nov 2016 14:28:49 +0100 From: Michal Hocko To: Michal Nazarewicz Cc: "Robin H. Johnson" , 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 Message-ID: <20161130132848.GG18432@dhcp22.suse.cz> References: <20161130092239.GD18437@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1780 Lines: 46 On Wed 30-11-16 14:08:00, Michal Nazarewicz wrote: > On Wed, Nov 30 2016, Michal Hocko wrote: > > [Let's CC linux-mm and Michal] > > > > On Tue 29-11-16 22:43:08, Robin H. Johnson wrote: > >> I didn't get any responses to this. > >> > >> git bisect shows that the problem did actually exist in 4.5.0-rc6, but > >> has gotten worse by many orders of magnitude (< 1/week to ~20M/hour). > >> > >> Presently with 4.9-rc5, it's now writing ~2.5GB/hour to syslog. > > > > This is really not helpful. I think we should simply make it pr_debug or > > need some ratelimitting. AFAIU the message is far from serious > > 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. --- diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 0fbfead6aa7d..96eb8d107582 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7424,7 +7424,7 @@ 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", + printk_ratelimited(KERN_DEBUG "%s: [%lx, %lx) PFNs busy\n", __func__, outer_start, end); ret = -EBUSY; goto done; I would also suggest to add dump_stack() to that path to see who is actually demanding so much large continuous blocks. -- Michal Hocko SUSE Labs