Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp862750imm; Wed, 23 May 2018 06:46:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqpz2abzYIXm8OPVrIIzkGJmLKlxNOnL+TIsa64hSoYHl/RQ2GcmAgqeByVSIn4myQe+tOO X-Received: by 2002:a63:9a49:: with SMTP id e9-v6mr2472249pgo.251.1527083190316; Wed, 23 May 2018 06:46:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527083190; cv=none; d=google.com; s=arc-20160816; b=01ViiawWrzDpJ9cfeTqS8vMZYdO1nJzQAqYcPKPaTXvousbwEXp9HKIy0n2KD70JUq tQK9pk2S8tCEQDco+5D5cHFi3VclfiJ5auxZJ+RS5hSVayPxNP3A+lAGZVcOoDgp1C+I zBPeuZx+O9N8ZyKsLQP0oWU+CBmxQbA6jtEutSMH5st/Z+zVt3LAJTidXfCA7rU6X81S NL3kvWIsNm4nCdwR8ZUdf1vGKWHIL8zydJlG+FDzBP5ytCUXUsxbVXxA6viP4/sVbemW 5y7sLTXPJwUmerJR+lF1EJwar7iuR1eZPMSHEaRTvdGlw2tVdFWv2tgI9/czgkS2UOOy 4yxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:from:cc:references:to :subject:arc-authentication-results; bh=lKnOXSyV11igFhzpK08yf4VJcgpjQ7XtGXv8ajqNAs8=; b=WjRaGXCUpwob6bQB+QKKnDP2v2euY3uYOC4YEmiqOS5UT0ws/GUwIt7AVsxI3VsvON rXP/MngfsDsG+ONQOY+6jKi3x4EwsCLeLZeaK+bsK0HcZZ3Nl3utjen3jV1TRbCokXki 2ERMGpaW+7g5cFWFHjjosHSo7uldven+g6ZCJxpyCZZ2EfjQEOYh9nk75RZACex+dq9z ZsRxK6bxDajGXb2MquZfADpItmf2NqpmOO+hGstSa2ej+CBh9LoT6ETOh+qNWprIt7KT ua3V2/hKbzHv7rZyxRUVR7j4tuoZXmuOrg3ku1yug1/fuPFT+oY77wdVcIn4t3BYhTfq lIqw== 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=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s14-v6si18516095plp.589.2018.05.23.06.46.14; Wed, 23 May 2018 06:46:30 -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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933056AbeEWNqE (ORCPT + 99 others); Wed, 23 May 2018 09:46:04 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:40764 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932941AbeEWNqD (ORCPT ); Wed, 23 May 2018 09:46:03 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4NDdLtv098528 for ; Wed, 23 May 2018 09:46:02 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j591fspwp-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 May 2018 09:46:02 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 23 May 2018 14:45:59 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 23 May 2018 14:45:55 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4NDjtNr62193762; Wed, 23 May 2018 13:45:55 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2E8764C058; Wed, 23 May 2018 14:37:35 +0100 (BST) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ECB844C046; Wed, 23 May 2018 14:37:32 +0100 (BST) Received: from [9.202.15.56] (unknown [9.202.15.56]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 23 May 2018 14:37:32 +0100 (BST) Subject: Re: [PATCH 2/2] mm: do not warn on offline nodes unless the specific node is explicitly requested To: Michal Hocko , Andrew Morton References: <20180523125555.30039-1-mhocko@kernel.org> <20180523125555.30039-3-mhocko@kernel.org> Cc: Oscar Salvador , Vlastimil Babka , Pavel Tatashin , Reza Arbab , Igor Mammedov , Vitaly Kuznetsov , LKML , linux-mm@kvack.org, Michal Hocko From: Anshuman Khandual Date: Wed, 23 May 2018 19:15:51 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20180523125555.30039-3-mhocko@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18052313-0012-0000-0000-000005D9C71C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18052313-0013-0000-0000-0000195711D7 Message-Id: <11e26a4e-552e-b1dc-316e-ce3e92973556@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-23_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805230140 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. But yes, if the request has __GFP_NOWARN it makes sense not to print any warning.