Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp1411901rdh; Fri, 24 Nov 2023 11:58:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IEWH/8m1/zsg1nWFd0euu0Lsr/Y2HY7Jr4UZ8IyuApyu6xP77TDc7bKVFms4Dc0WVKZMED/ X-Received: by 2002:a17:902:e812:b0:1cc:5671:8d9 with SMTP id u18-20020a170902e81200b001cc567108d9mr10152169plg.27.1700855931409; Fri, 24 Nov 2023 11:58:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700855931; cv=none; d=google.com; s=arc-20160816; b=JBdgoVCqbGC82YabkU48aYr/9RIE58J19xk/KFcpbvw8FxRuH8adcqnuUBgGh4gogM iLEtwDe7IcaXmzBCBM2py/NoHQWnQsCqcbALy/xKoBz1Qw8NuWQVXCvzkAvbiYcK83LY XkfiTzgp0/zc3s7stHMrPf3VjaeuP4s7Lo4RNtciHpoHHrxXJbu1Nyah0Ar/h7+UGMTg fSQaM7r303rdD/fnajnFUy5jGwWQFr7AaLxVpK0N0e6ZwNd/llWBfNoKF060M5yrddHT vVvI9T3P9gQtR4yffMAJjRF7LFMwdf8BzGI89JZtJuXqMGX4Wt0aWTNOTGO1/qBTliMM +3xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=ybZHlf/mJ5/agtbykqICZuSlViY9e9I6Dg/UHiB8cLQ=; fh=3mTZp6NUq5b0XFU4zEiQt2d+Ch7kThbH2U6WKlEWkKU=; b=0UgiZpAR1OaVUodSf56NODilMg8hGifPkZHjDdJM+d48AAraB3jQfhUCLfTyvRr5SD bUeInzNHSKuObpIUgBK5+HC61ygViZTaGgHrPG0lt6V0JsYEdMUA59XXMPrL7/91zZpB Gy8FE4LlatoGXWwMsuGJMl0ELFL+Is5PL6xGWvMdTze/lEBS2VoxVrb0fMhRAppKs52L OFSS+DrFraoWjIs/GsBtoajypHYOSE+gwbfz+8VilpO6QzIhejrIErm2DzWFwDMrY/J4 faFue46DSwwsDAB2L+u9FCKqTOed/DtPuP+TnPD6wu1psrIxVD2WyoTH5L/S3oe32+wt ZPAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=erN7nkvw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 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 agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id k2-20020a170902ce0200b001bdc10170casi4307059plg.36.2023.11.24.11.58.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Nov 2023 11:58:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=erN7nkvw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id A8EA181D3AFC; Fri, 24 Nov 2023 11:58:48 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231937AbjKXT56 (ORCPT + 99 others); Fri, 24 Nov 2023 14:57:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231860AbjKXT54 (ORCPT ); Fri, 24 Nov 2023 14:57:56 -0500 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 CE6A61985 for ; Fri, 24 Nov 2023 11:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700855882; 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=ybZHlf/mJ5/agtbykqICZuSlViY9e9I6Dg/UHiB8cLQ=; b=erN7nkvweqNrlLQB6ypKGRvL/GBd73AthtFjModZoWPm122byudHBSBVv2LV0bvMwdGMUy Q6y8CN6SCcn+LvL+0YguzXCyRCmYErJNExzQP5lgduRwuQaPsoIezzUqS8giNRgOfU1h87 WYw2dqFynwJqhHskP5CH6rCBFiu5iT4= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-115-UO0m5vkXNr-M-vmDPfxr6Q-1; Fri, 24 Nov 2023 14:57:58 -0500 X-MC-Unique: UO0m5vkXNr-M-vmDPfxr6Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 26F051C0515B; Fri, 24 Nov 2023 19:57:58 +0000 (UTC) Received: from Diego (unknown [10.39.208.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7B15F2026D68; Fri, 24 Nov 2023 19:57:55 +0000 (UTC) Date: Fri, 24 Nov 2023 20:57:52 +0100 (CET) From: Michael Petlan X-X-Sender: Michael@Diego To: Nick Forrington cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Arnaldo Carvalho de Melo , vmolnaro@redhat.com Subject: Re: [PATCH] perf test: Remove atomics from test_loop to avoid test failures In-Reply-To: <20231102162225.50028-1-nick.forrington@arm.com> Message-ID: References: <20231102162225.50028-1-nick.forrington@arm.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 24 Nov 2023 11:58:49 -0800 (PST) On Thu, 2 Nov 2023, Nick Forrington wrote: > The current use of atomics can lead to test failures, as tests (such as > tests/shell/record.sh) search for samples with "test_loop" as the > top-most stack frame, but find frames related to the atomic operation > (e.g. __aarch64_ldadd4_relax). > > This change simply removes the "count" variable, as it is not necessary. Hello. I believe that it was there to prevent the compiler to optimize the loop out or some reason like that. Hopefully, it will work even without that on all architectures with all compilers that are used for building perf... I also think that the tests should be designed in a more robust way, so that they aren't directly dependent on exact stack frames, e.g. let's look at the "inet_pton" testcase... The inet_pton test result check algorithm is designed to rely on exact stacktrace, without a possibility to specify something like "we want this and that in the stack trace, but otherwise, it does not matter which wrappers are aroung". Then there must be the following code to adjust the expected output exactly per architecture: echo "ping[][0-9 \.:]+$event_name: \([[:xdigit:]]+\)" > $expected echo ".*inet_pton\+0x[[:xdigit:]]+[[:space:]]\($libc|inlined\)$" >> $expected case "$(uname -m)" in s390x) eventattr='call-graph=dwarf,max-stack=4' echo "(__GI_)?getaddrinfo\+0x[[:xdigit:]]+[[:space:]]\($libc|inlined\)$" >> $expected echo "main\+0x[[:xdigit:]]+[[:space:]]\(.*/bin/ping.*\)$" >> $expected ;; ppc64|ppc64le) eventattr='max-stack=4' echo "gaih_inet.*\+0x[[:xdigit:]]+[[:space:]]\($libc\)$" >> $expected echo "getaddrinfo\+0x[[:xdigit:]]+[[:space:]]\($libc\)$" >> $expected echo ".*(\+0x[[:xdigit:]]+|\[unknown\])[[:space:]]\(.*/bin/ping.*\)$" >> $expected ;; *) eventattr='max-stack=3' echo ".*(\+0x[[:xdigit:]]+|\[unknown\])[[:space:]]\(.*/bin/ping.*\)$" >> $expected ;; esac Of course, since it relies on libc version, then we need patches, such as 1f85d016768f ("perf test record+probe_libc_inet_pton: Fix call chain match on x86_64") 311693ce81c9 ("perf test record+probe_libc_inet_pton: Fix call chain match on s390") fb710ddee75f ("perf test record_probe_libc_inet_pton: Fix test on s/390 where 'text_to_binary_address' now appears on the backtrace") ... which break the test when used with older libc... I think that a better design of such test is either probing some program of ourselves that has predictable and stable function call sequence or be more robust in checking the stack trace. Thoughts? Michael > > Fixes: 1962ab6f6e0b ("perf test workload thloop: Make count increments atomic") > Signed-off-by: Nick Forrington > --- > tools/perf/tests/workloads/thloop.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/tools/perf/tests/workloads/thloop.c b/tools/perf/tests/workloads/thloop.c > index af05269c2eb8..457b29f91c3e 100644 > --- a/tools/perf/tests/workloads/thloop.c > +++ b/tools/perf/tests/workloads/thloop.c > @@ -7,7 +7,6 @@ > #include "../tests.h" > > static volatile sig_atomic_t done; > -static volatile unsigned count; > > /* We want to check this symbol in perf report */ > noinline void test_loop(void); > @@ -19,8 +18,7 @@ static void sighandler(int sig __maybe_unused) > > noinline void test_loop(void) > { > - while (!done) > - __atomic_fetch_add(&count, 1, __ATOMIC_RELAXED); > + while (!done); > } > > static void *thfunc(void *arg) > -- > 2.42.0 > > >