From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754502AbdKFSPl convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Mon, 6 Nov 2017 13:15:41 -0500
Received: from userp1040.oracle.com ([156.151.31.81]:18297 "EHLO
        userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754368AbdKFSPd (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 6 Nov 2017 13:15:33 -0500
Message-ID: <1509992067.4140.1.camel@oracle.com>
Subject: Re: [PATCH] mm, sparse: do not swamp log with huge vmemmap
 allocation failures
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Johannes Weiner <hannes@cmpxchg.org>
Cc: Vlastimil Babka <vbabka@suse.cz>, linux-mm@kvack.org,
        LKML <linux-kernel@vger.kernel.org>, Michal Hocko <mhocko@suse.com>
Date: Mon, 06 Nov 2017 11:14:27 -0700
In-Reply-To: <20171106092228.31098-1-mhocko@kernel.org>
References: <20171106092228.31098-1-mhocko@kernel.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.6-1ubuntu1 
Mime-Version: 1.0
Content-Transfer-Encoding: 8BIT
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 2017-11-06 at 10:22 +0100, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> While doing a memory hotplug tests under a heavy memory pressure we
> have
> noticed too many page allocation failures when allocating vmemmap
> memmap
> backed by huge page
> ......... deleted .........
> +
> +		if (!warned) {
> +			warn_alloc(gfp_mask, NULL, "vmemmap alloc
> failure: order:%u", order);
> +			warned = true;
> +		}
>  		return NULL;
>  	} else
>  		return __earlyonly_bootmem_alloc(node, size, size,

This will warn once and only once after a kernel is booted. This
condition may happen repeatedly over a long period of time with
significant time span between two such events and it can be useful to
know if this is happening repeatedly. There might be better ways to
throttle the rate of warnings, something like warn once and then
suppress warnings for the next 15 minutes (or pick any other time
frame). If this condition happens again later, there will be another
warning.

--
Khalid