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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5ABDC433EF for ; Tue, 12 Apr 2022 07:53:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 424826B0078; Tue, 12 Apr 2022 03:53:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D4886B007B; Tue, 12 Apr 2022 03:53:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29BFE6B007D; Tue, 12 Apr 2022 03:53:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 1C3156B0078 for ; Tue, 12 Apr 2022 03:53:48 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DBB0721F54 for ; Tue, 12 Apr 2022 07:53:47 +0000 (UTC) X-FDA: 79347462894.18.6D4D6E1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 487471C0004 for ; Tue, 12 Apr 2022 07:53:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649750026; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0ujqJu26XZaURO2/0izAa77Jm9Xc4e+oAvHMxBGFaCI=; b=MACz7hsl1dtRuVeSJc6jk09EuPM6p8FxYIaiIP3+gzuhggtD6b0ccyZsGpsRZbBT1dA9El Bh3LSbm8lvBjiNKMKC+wZKiqWKIuDKXIT8xaSekb1knvz9wWbZnnTLsmP7/e8c44vlqmAS 9fIIvJ3Bkpwgxw5MwrcYbAU53GmgcS4= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-540-W6FaP8DbN-aaPqZahtMGWg-1; Tue, 12 Apr 2022 03:53:45 -0400 X-MC-Unique: W6FaP8DbN-aaPqZahtMGWg-1 Received: by mail-ed1-f70.google.com with SMTP id ee36-20020a056402292400b0041d836b664cso2429764edb.6 for ; Tue, 12 Apr 2022 00:53:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=0ujqJu26XZaURO2/0izAa77Jm9Xc4e+oAvHMxBGFaCI=; b=WLYo88OSlviMiqi8Y1m9nwA2O/uj6liocaJU0PgONP/70LZOKKTjMG6EsCLCByHxT+ 7FtPoTX9to/nDzrETay7WQaxOX5y+cJkyvbs3HKXp7/EP/dJ+KyVBzjuYAAo+AJaxc81 iGsNdS/IERrbJSOzvSGtM6kbc1vHUOa0bYNgdjTCR+1+hfGwQBWtfYMwjTXmwlDRrjoe ptEZVSEATKFsLePhS1gYTUAQ3YlBg2LT2uJwNX7r1q92ACP1qPBCszaPnawoO+QRLKrB /LIlM/RNrxRG70zPaDz92U/Za9zs+ovrkUcCRjTH+XxUf5JkGdu7n5MNlDaTGo9n8E67 2/bw== X-Gm-Message-State: AOAM530KaYOg+Oyk7Xqk0900L0K0ClDacSnfAy8VREEP6/tZFYT2Eqh5 XZwaH+th9n4jjf0Fhpn8viL1IxdmjKQPO6vU4QHLqgA+4lgh/WgIDXS58KN4ZqLGfJsXMnnVJtd pfV5SEhALcGg= X-Received: by 2002:a05:6402:2318:b0:413:7645:fa51 with SMTP id l24-20020a056402231800b004137645fa51mr37838283eda.201.1649750024566; Tue, 12 Apr 2022 00:53:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLS4c+05fj01E/2mxyMWnglOUVP+1QZvTBDo7mwKNb7SlOvaMLyKzwcVjmtkcKf8Ch69xy1w== X-Received: by 2002:a05:6402:2318:b0:413:7645:fa51 with SMTP id l24-20020a056402231800b004137645fa51mr37838270eda.201.1649750024325; Tue, 12 Apr 2022 00:53:44 -0700 (PDT) Received: from ?IPV6:2003:cb:c707:1800:7c14:16cc:5291:a9f3? (p200300cbc70718007c1416cc5291a9f3.dip0.t-ipconnect.de. [2003:cb:c707:1800:7c14:16cc:5291:a9f3]) by smtp.gmail.com with ESMTPSA id qb10-20020a1709077e8a00b006e892cf471asm2210617ejc.84.2022.04.12.00.53.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Apr 2022 00:53:30 -0700 (PDT) Message-ID: <22fe2724-e011-80b4-04f1-cca2c35aadb6@redhat.com> Date: Tue, 12 Apr 2022 09:53:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [Patch v2 2/2] mm/page_alloc: not necessary to multiply MAX_NODE_LOAD To: Vlastimil Babka , Wei Yang Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Oscar Salvador References: <20220408025947.1619-1-richard.weiyang@gmail.com> <20220408025947.1619-2-richard.weiyang@gmail.com> <20220408230726.qjz7x5wvkxsurvgq@master> <39bd76b2-5e84-3b7e-c3d6-e8e834d96035@suse.cz> From: David Hildenbrand Organization: Red Hat In-Reply-To: <39bd76b2-5e84-3b7e-c3d6-e8e834d96035@suse.cz> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: fh6owtbq69akg6odspjatxwi5kywt8b3 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=MACz7hsl; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 487471C0004 X-HE-Tag: 1649750027-961103 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11.04.22 12:52, Vlastimil Babka wrote: > On 4/9/22 01:07, Wei Yang wrote: >> On Fri, Apr 08, 2022 at 10:09:48AM +0200, David Hildenbrand wrote: >>> On 08.04.22 04:59, Wei Yang wrote: >>>> Since we just increase a constance of 1 to node penalty, it is not >>>> necessary to multiply MAX_NODE_LOAD for preference. >>>> >>>> This patch also remove the definition. >>>> >>>> [vbabka@suse.cz: suggests] >>>> >>>> Signed-off-by: Wei Yang >>>> CC: Vlastimil Babka >>>> CC: David Hildenbrand >>>> CC: Oscar Salvador >>>> --- >>>> mm/page_alloc.c | 3 +-- >>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>> >>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>>> index 86b6573fbeb5..ca6a127bbc26 100644 >>>> --- a/mm/page_alloc.c >>>> +++ b/mm/page_alloc.c >>>> @@ -6170,7 +6170,6 @@ int numa_zonelist_order_handler(struct ctl_table *table, int write, >>>> } >>>> >>>> >>>> -#define MAX_NODE_LOAD (nr_online_nodes) >>>> static int node_load[MAX_NUMNODES]; >>>> >>>> /** >>>> @@ -6217,7 +6216,7 @@ int find_next_best_node(int node, nodemask_t *used_node_mask) >>>> val += PENALTY_FOR_NODE_WITH_CPUS; >>>> >>>> /* Slight preference for less loaded node */ >>>> - val *= (MAX_NODE_LOAD*MAX_NUMNODES); >>>> + val *= MAX_NUMNODES; >>>> val += node_load[n]; >>>> >>>> if (val < min_val) { >>> >>> I feel like this should be squashed into the previous patch. It has the >>> same effect of making this code independent of nr_online_nodes. And I >>> had to scratch my head a couple of times in patch #1 why the change in >>> patch #1 is fine with thus remaining in place. >>> >>> >>> Having that said, I consider this code highly unnecessary >>> over-complicated at first sight. Removing some of the magic most >>> certainly is very welcome. >>> >>> This semantics of the global variable node_load[] remains mostly >>> mysterious for me. > > Looks like after this patch(es), it would be "how many times was this node > picked as the first fallback out of nodes with the same distance"? Yeah, that makes sense. I'd appreciate if we'd just stop using a global variable here and pass it as a parameter. But that's obviously an independent cleanup. -- Thanks, David / dhildenb