From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99810C433E7 for ; Mon, 19 Oct 2020 07:06:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 08DA622260 for ; Mon, 19 Oct 2020 07:06:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="MOLs08/j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 08DA622260 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0AB876B0068; Mon, 19 Oct 2020 03:06:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05D096B006C; Mon, 19 Oct 2020 03:06:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8D8A6B006E; Mon, 19 Oct 2020 03:06:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0076.hostedemail.com [216.40.44.76]) by kanga.kvack.org (Postfix) with ESMTP id B97AE6B0068 for ; Mon, 19 Oct 2020 03:06:53 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 588AA362A for ; Mon, 19 Oct 2020 07:06:53 +0000 (UTC) X-FDA: 77387792706.14.table96_2e0fc5727235 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 3765E18229835 for ; Mon, 19 Oct 2020 07:06:53 +0000 (UTC) X-HE-Tag: table96_2e0fc5727235 X-Filterd-Recvd-Size: 2615 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Mon, 19 Oct 2020 07:06:52 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1603091211; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cZoc8etLME1TcrchebfctJW/RG6gpIbgrhS4J7nrH+g=; b=MOLs08/jyBYO0a8WqiloLXgfVyXyoZierMjNWwvdlcmN77l6XFYgA7MYYyDvuTGsswptlF N3u5xlF8itd5qQzYmVyxYlt3AaTgjmHqfyz/ZQZXhtGM4U7oEICAlcwHJaA+MFWE6Z0haC QvZ+pe7dZthbQ3cQf/K/B0OwnCAavCQ= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C15E4B8FC; Mon, 19 Oct 2020 07:06:50 +0000 (UTC) Date: Mon, 19 Oct 2020 09:06:44 +0200 From: Michal Hocko To: Tianxianting Cc: "cl@linux.com" , "penberg@kernel.org" , "rientjes@google.com" , "iamjoonsoo.kim@lge.com" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "kuba@kernel.org" , "alexei.starovoitov@gmail.com" Subject: Re: [PATCH] mm: Make allocator take care of memoryless numa node Message-ID: <20201019070644.GB27114@dhcp22.suse.cz> References: <20201012082739.15661-1-tian.xianting@h3c.com> <20201012150554.GE29725@dhcp22.suse.cz> <10ae851702e346369db44e1ec9c830fb@h3c.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10ae851702e346369db44e1ec9c830fb@h3c.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun 18-10-20 14:18:37, Tianxianting wrote: > Thanks for the comments > I found in current code, there are two places to call > local_memory_node(node) before calling kzalloc_node(), I think we can > remove them? I am not sure which code you are talking about. git grep shows me 2 places in blk-mq code (e.g. bffed457160ab) and that looks quite bogus to me. Bring that up with the respective maintainer and Raghavendra. The changelog doesn't really describe any problem, if there is any. But from the allocator semantic point of view memory less nodes are to be expected and the allocator should fallback to the proper node. As long as __GFP_THISNODE is not enforced of course. -- Michal Hocko SUSE Labs