From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933833AbdGKVZt (ORCPT ); Tue, 11 Jul 2017 17:25:49 -0400 Received: from mx2.suse.de ([195.135.220.15]:41510 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933513AbdGKVZs (ORCPT ); Tue, 11 Jul 2017 17:25:48 -0400 Date: Tue, 11 Jul 2017 23:25:45 +0200 From: Michal Hocko To: Johannes Weiner Cc: Andrew Morton , Cristopher Lameter , Vlastimil Babka , linux-mm@kvack.org, LKML Subject: Re: [PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap Message-ID: <20170711212544.GA25122@dhcp22.suse.cz> References: <20170711134204.20545-1-mhocko@kernel.org> <20170711142558.GE11936@dhcp22.suse.cz> <20170711172623.GB961@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170711172623.GB961@cmpxchg.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 11-07-17 13:26:23, Johannes Weiner wrote: > Hi Michael, > > On Tue, Jul 11, 2017 at 04:25:58PM +0200, Michal Hocko wrote: > > Ohh, scratch that. The patch is bogus. I have completely missed that > > vmemmap_populate_hugepages already falls back to > > vmemmap_populate_basepages. I have to revisit the bug report I have > > received to see what happened apart from the allocation warning. Maybe > > we just want to silent that warning. > > Yep, this should be fixed in 8e2cdbcb86b0 ("x86-64: fall back to > regular page vmemmap on allocation failure"). > > I figure it's good to keep some sort of warning there, though, as it > could have performance implications when we fall back to base pages. Yeah, but I am not really sure the allocation warning is the right thing here because it is just too verbose. If you consider that we will get this warning for each memory section (128MB or 2GB)... I guess the existing pr_warn_once("vmemmap: falling back to regular page backing\n"); or maybe make it pr_warn should be enough. What do you think? -- Michal Hocko SUSE Labs