Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp508572rwr; Wed, 26 Apr 2023 02:26:10 -0700 (PDT) X-Google-Smtp-Source: AKy350bjtCZSEzz3B0RgLbxGphGCnTBVIldHyECmd0tK8Niovm2lpBPnNJVzwgPMyQrkHbSu5oaZ X-Received: by 2002:a17:90a:2a03:b0:249:86bd:42a7 with SMTP id i3-20020a17090a2a0300b0024986bd42a7mr19648834pjd.42.1682501170391; Wed, 26 Apr 2023 02:26:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682501170; cv=none; d=google.com; s=arc-20160816; b=kldFF/lCLBFBfnLSXGOqp0C2c+jRHeHjVIRjQYA6lADiG8c7y7Mz/PkCux+5Z1aofe Qnw/LXk+ObzFrhC8mSVkfN4inLE6ebMNWhPw5EFnD2xsqv0WJzOu9Q2GRx0ftIHY2Jf1 HgJWFqQlyQ1F/Mvqj+ElUS1T6cR+htHHJwVvlqeynATC/WZOvJ4AHyPlGFaDlFQGCWc+ H3pHVW+RYlW1Y14+2WHZtQTziPtQQm3R9Ww4bmuo37JcGmV1e3xbKlBpsnF3Kv2qfDlf FtKVVou6MJC5F7tj5T+xmWO3iziMwrCcNZtA32AgR7jgG2ChXNIdiOuXlrizTCHYvtQ6 cvqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=Fyxo9X49FJOFaiRGnal9ZnS5FLek6M+ko6PrXrYgFok=; b=K4ie26inzfX+R6jQwxQWS7w8tm07xeF3Q0LR5w752AUIaprftwuhpTJrU+XeIHEIMo f8wyhDXucf7p2XRcIErowIV7cvzNupFsWIUXgLqT85xgRdRH9xM70cT5KbsrCotIyalO kbJQcYzqG2z/Ibrcj+URE1+rl1S+dQOQGko8SKex9/Q8irnESygjQCq7XVASl0k30cAi 5oAV+Z+7yKyjf51inLvj3uCx/D6ijDnRt8qoE54caoY7xLMckYn27DaMESitpkC2cNnW 1aca+aT4kRuLq1qH36wCTZTAvupXdj+H7vThcHGiV3GpixawsB8nYI48faPXG5V2Nf9e 3zrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fhItSkiq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n9-20020a17090a9f0900b0023d22d0f0fdsi18396525pjp.19.2023.04.26.02.25.59; Wed, 26 Apr 2023 02:26:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fhItSkiq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240321AbjDZJUq (ORCPT + 99 others); Wed, 26 Apr 2023 05:20:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240460AbjDZJUe (ORCPT ); Wed, 26 Apr 2023 05:20:34 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9FEE49E0 for ; Wed, 26 Apr 2023 02:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682500650; 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=Fyxo9X49FJOFaiRGnal9ZnS5FLek6M+ko6PrXrYgFok=; b=fhItSkiq8a84EmiEwms94TrIMQkZLVnAASsSsUK22aqdqS35KxiFfmnBMnQbzAxAQxLwGw ttyaFyRhRKS4jrx2dh/+rkXb9Z7KQ0OMyZkS0//KAVgZ+XBbGiU7bTPQUgUdVwjvLZ17FY Ce1Xr/GimC/pwz+rv5TL3I0NZe+LdXU= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-547-6cV1rc4jOwiPUzcSEc19UQ-1; Wed, 26 Apr 2023 05:17:28 -0400 X-MC-Unique: 6cV1rc4jOwiPUzcSEc19UQ-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-3f171d38db3so39802635e9.0 for ; Wed, 26 Apr 2023 02:17:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682500647; x=1685092647; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Fyxo9X49FJOFaiRGnal9ZnS5FLek6M+ko6PrXrYgFok=; b=GJj+aXQjzcQ+Qp2hC1hpQVHiiTpHk2nKXilmfqNZaqzmJGytNTRe6jIVMeoVPnAP8B ekG0z5kCwANTSC6bum/DeJK65ycdYOt9wM6L7q0sRNGR0H9Uy+vCATPmbVbngkFa3dL9 X2A8rbta1iida1JWAoprQ+pKJIHmNTsrbIPgfylPDtROv5/Y2Rv2nuC70JkKv8l4gBg+ cWazE0z1cR4HAbmsZDmA26ztU9gibX19z5ky4do+cT5QW4wJkTFzxMZOXqwmMkr/v4Fw OruTsSGhIBJpj3TmV/BVAYj0aXr+5QvYVTQnVr1P2AFVEY7EBAn8+IS6mRjpIOq6gvT6 uOwg== X-Gm-Message-State: AAQBX9fL9XZzDz7bS6WmWyJwmpDXPQR7npGQ9Hu0at1WEiZOs5WO5prp HxHvHrGO3tg1yvO6hYgTwTzZA9ZZ31K2vwX/z+BmCFV4lDBftYRN25eWNmGdgG/lyBVmDYfBWd1 SLVWEuJR6unCvgWNTQTJ3y9Wa X-Received: by 2002:a7b:cc98:0:b0:3f1:6ebe:d598 with SMTP id p24-20020a7bcc98000000b003f16ebed598mr12093495wma.7.1682500647492; Wed, 26 Apr 2023 02:17:27 -0700 (PDT) X-Received: by 2002:a7b:cc98:0:b0:3f1:6ebe:d598 with SMTP id p24-20020a7bcc98000000b003f16ebed598mr12093489wma.7.1682500647247; Wed, 26 Apr 2023 02:17:27 -0700 (PDT) Received: from vschneid.remote.csb ([154.57.232.159]) by smtp.gmail.com with ESMTPSA id e16-20020a5d5950000000b0030490c8ccafsm3246491wri.52.2023.04.26.02.17.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 02:17:26 -0700 (PDT) From: Valentin Schneider To: Yury Norov Cc: Jakub Kicinski , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Saeed Mahameed , Pawel Chmielewski , Leon Romanovsky , "David S. Miller" , Eric Dumazet , Paolo Abeni , Andy Shevchenko , Rasmus Villemoes , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Tariq Toukan , Gal Pressman , Greg Kroah-Hartman , Heiko Carstens , Barry Song Subject: Re: [PATCH v2 7/8] lib: add test for for_each_numa_{cpu,hop_mask}() In-Reply-To: References: <20230420051946.7463-1-yury.norov@gmail.com> <20230420051946.7463-8-yury.norov@gmail.com> Date: Wed, 26 Apr 2023 10:17:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/04/23 22:50, Yury Norov wrote: > Hi Valentin, > > Thanks for review! > > On Mon, Apr 24, 2023 at 06:09:52PM +0100, Valentin Schneider wrote: >> On 19/04/23 22:19, Yury Norov wrote: >> > + for (node = 0; node < sched_domains_numa_levels; node++) { >> > + unsigned int hop, c = 0; >> > + >> > + rcu_read_lock(); >> > + for_each_numa_cpu(cpu, hop, node, cpu_online_mask) >> > + expect_eq_uint(cpumask_local_spread(c++, node), cpu); >> > + rcu_read_unlock(); >> > + } >> >> I'm not fond of the export of sched_domains_numa_levels, especially >> considering it's just there for tests. >> >> Furthermore, is there any value is testing parity with >> cpumask_local_spread()? > > I wanted to emphasize that new NUMA-aware functions are coherent with > each other, just like find_nth_bit() is coherent with find_next_bit(). > > But all that coherence looks important only in non-NUMA case, because > client code may depend on fact that next CPU is never less than current. > This doesn't hold for NUMA iterators anyways... > Ah right, I see your point. But yes, distance-ordered walks break this assumption. >> Rather, shouldn't we check that using this API does >> yield CPUs of increasing NUMA distance? >> >> Something like >> >> for_each_node(node) { >> unsigned int prev_cpu, hop = 0; >> >> cpu = cpumask_first(cpumask_of_node(node)); >> prev_cpu = cpu; >> >> rcu_read_lock(); >> >> /* Assert distance is monotonically increasing */ >> for_each_numa_cpu(cpu, hop, node, cpu_online_mask) { >> expect_ge_uint(cpu_to_node(cpu), cpu_to_node(prev_cpu)); >> prev_cpu = cpu; >> } >> >> rcu_read_unlock(); >> } > > Your version of the test looks more straightforward. I need to think > for more, but it looks like I can take it in v3. > I realized I only wrote half the relevant code - comparing node IDs is meaningless, I meant to compare distances as we walk through the CPUs... I tested the below against a few NUMA topologies and it seems to be sane: diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c index 6becb044a66f0..8f8512d139d58 100644 --- a/lib/test_bitmap.c +++ b/lib/test_bitmap.c @@ -174,11 +174,23 @@ __check_eq_str(const char *srcfile, unsigned int line, return eq; } -#define __expect_eq(suffix, ...) \ +static bool __init +__check_ge_uint(const char *srcfile, unsigned int line, + const unsigned int a, unsigned int b) +{ + if (a < b) { + pr_err("[%s:%u] expected a(%u) >= b(%u)\n", + srcfile, line, a, b); + return false; + } + return true; +} + +#define __expect_op(op, suffix, ...) \ ({ \ int result = 0; \ total_tests++; \ - if (!__check_eq_ ## suffix(__FILE__, __LINE__, \ + if (!__check_## op ## _ ## suffix(__FILE__, __LINE__, \ ##__VA_ARGS__)) { \ failed_tests++; \ result = 1; \ @@ -186,6 +198,9 @@ __check_eq_str(const char *srcfile, unsigned int line, result; \ }) +#define __expect_eq(suffix, ...) __expect_op(eq, suffix, ##__VA_ARGS__) +#define __expect_ge(suffix, ...) __expect_op(ge, suffix, ##__VA_ARGS__) + #define expect_eq_uint(...) __expect_eq(uint, ##__VA_ARGS__) #define expect_eq_bitmap(...) __expect_eq(bitmap, ##__VA_ARGS__) #define expect_eq_pbl(...) __expect_eq(pbl, ##__VA_ARGS__) @@ -193,6 +208,8 @@ __check_eq_str(const char *srcfile, unsigned int line, #define expect_eq_clump8(...) __expect_eq(clump8, ##__VA_ARGS__) #define expect_eq_str(...) __expect_eq(str, ##__VA_ARGS__) +#define expect_ge_uint(...) __expect_ge(uint, ##__VA_ARGS__) + static void __init test_zero_clear(void) { DECLARE_BITMAP(bmap, 1024); @@ -756,12 +773,23 @@ static void __init test_for_each_numa(void) { unsigned int cpu, node; - for (node = 0; node < sched_domains_numa_levels; node++) { - unsigned int hop, c = 0; + for_each_node(node) { + unsigned int start_cpu, prev_dist, hop = 0; + + cpu = cpumask_first(cpumask_of_node(node)); + prev_dist = node_distance(node, node); + start_cpu = cpu; rcu_read_lock(); - for_each_numa_cpu(cpu, hop, node, cpu_online_mask) - expect_eq_uint(cpumask_local_spread(c++, node), cpu); + + /* Assert distance is monotonically increasing */ + for_each_numa_cpu(cpu, hop, node, cpu_online_mask) { + unsigned int dist = node_distance(cpu_to_node(cpu), cpu_to_node(start_cpu)); + + expect_ge_uint(dist, prev_dist); + prev_dist = dist; + } + rcu_read_unlock(); } }