Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp888990imm; Wed, 23 May 2018 07:07:05 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr8u5O5U/j+XSz+IbZV88aBcyjTtMR9k22gfJJ5aWUCsP22SXnChrYjkGRYt0VfmexdbNSE X-Received: by 2002:a17:902:780a:: with SMTP id p10-v6mr3128135pll.281.1527084425595; Wed, 23 May 2018 07:07:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527084425; cv=none; d=google.com; s=arc-20160816; b=m1CgkeUhtSUfpEvnj+bXfMXuXkAKm9GoySwDSD0t9MjS8zwj7SQMw7dtaTDT9yAmE5 h9HiFfoYWTW26OcyMSUTjzgdGbYKQU6AxTRVNWGcxy9G5DZJj05+AlGpl9EPZGkCJ3Lr SdP7Vx5OWauJeSflysk1sqpaNfmmfpfgrCAw7aJWmWtwt4cz7mdkcRW4FLTFsvqBf8p7 WiGZgYGN6eQUZAaN7fgOw2chhvFXA+zs+dkOfEG8s+ikWSu6qZR3WV4IsazLSC7GbwV2 7zODg9H+EzuUMm+VXJx6McQdOAo7c/ERMtTUM28ZPK2MfTsQ5DPxFHXSfkyS+DBEOrEr JpiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=jNBNTAeUP3hGkqUlBzKeM+qHr/7atE716DqCFKDgtF4=; b=yGytCFmBBFsvpD4qOZxzHzfvgEWZBLRVbbnQk41f+k33AJ3pOM1zqpAfFJL+uHM6wo AwJc+hPBiZflslMzw5IHx+ioHGz4NlGHOwYExgw1CdAsOhMR514XLqZjM9FrxfbKkspd yeVqNpgZMPaoUBN4bFrJ8MMnBLEAqV8rMx4HeyTxUOlVJq1fMh4jHCG9Uc4ZRwlt40kq sXYgJkaEdwrm7TDlho3PYUkR59500XaCsBB8NpJqIuDd4ecpdGX6d06ryqtw6+J10Jjc 6Ny3mthmHznWqGjpdHae+PCCe66hQej14pcWiBkwX0Zd0rtA4Nk3NeGvGzsX6cYoYQM+ o+cg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w9-v6si19494617plk.28.2018.05.23.07.06.50; Wed, 23 May 2018 07:07:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933204AbeEWOGK (ORCPT + 99 others); Wed, 23 May 2018 10:06:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:60404 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932942AbeEWOGH (ORCPT ); Wed, 23 May 2018 10:06:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0622BAE79; Wed, 23 May 2018 14:06:06 +0000 (UTC) Date: Wed, 23 May 2018 16:06:02 +0200 From: Michal Hocko To: Anshuman Khandual Cc: Andrew Morton , Oscar Salvador , Vlastimil Babka , Pavel Tatashin , Reza Arbab , Igor Mammedov , Vitaly Kuznetsov , LKML , linux-mm@kvack.org Subject: Re: [PATCH 2/2] mm: do not warn on offline nodes unless the specific node is explicitly requested Message-ID: <20180523140601.GQ20441@dhcp22.suse.cz> References: <20180523125555.30039-1-mhocko@kernel.org> <20180523125555.30039-3-mhocko@kernel.org> <11e26a4e-552e-b1dc-316e-ce3e92973556@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11e26a4e-552e-b1dc-316e-ce3e92973556@linux.vnet.ibm.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 23-05-18 19:15:51, Anshuman Khandual wrote: > On 05/23/2018 06:25 PM, Michal Hocko wrote: > > when adding memory to a node that is currently offline. > > > > The VM_WARN_ON is just too loud without a good reason. In this > > particular case we are doing > > alloc_pages_node(node, GFP_KERNEL|__GFP_RETRY_MAYFAIL|__GFP_NOWARN, order) > > > > so we do not insist on allocating from the given node (it is more a > > hint) so we can fall back to any other populated node and moreover we > > explicitly ask to not warn for the allocation failure. > > > > Soften the warning only to cases when somebody asks for the given node > > explicitly by __GFP_THISNODE. > > node hint passed here eventually goes into __alloc_pages_nodemask() > function which then picks up the applicable zonelist irrespective of > the GFP flag __GFP_THISNODE. __GFP_THISNODE should enforce the given node without any fallbacks unless something has changed recently. > Though we can go into zones of other > nodes if the present node (whose zonelist got picked up) does not > have any memory in it's zones. So warning here might not be without > any reason. I am not sure I follow. Are you suggesting a different VM_WARN_ON? -- Michal Hocko SUSE Labs