From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 663163858D37 for ; Wed, 17 Aug 2022 13:45:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 663163858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (unknown [178.228.156.55]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id EDDA1300070C; Wed, 17 Aug 2022 15:45:15 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 5DBEB2E8182C; Wed, 17 Aug 2022 15:45:13 +0200 (CEST) Date: Wed, 17 Aug 2022 15:45:13 +0200 From: Mark Wielaard To: Florian Weimer Cc: Thomas Fitzsimmons , 'GNU C Library' , Wilco Dijkstra , "Frank Ch. Eigler" Subject: Re: [PATCH] Improve performance of IO locks Message-ID: References: <878rnoeja2.fsf@oldenburg.str.redhat.com> <87pmh0cxh8.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pmh0cxh8.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2022 13:45:18 -0000 Hi Florian, On Tue, Aug 16, 2022 at 12:08:03PM +0200, Florian Weimer wrote: > * Mark Wielaard: > > Yeah, I am actually surprised just reverting the patch fixed things. > > But looking at the bunsen data for glibc-debian-ppc64 does seem to > > show that the only thing changed is this particular patch. Runs before > > it pass, runs after show lots of fails. > > > > https://builder.sourceware.org/testruns/?has_keyvalue_like_k=testrun.git_describe&has_keyvalue_like_v=%25glibc-debian-ppc64%25 > > How do I read this table? Glad you ask! Although I think the mystery of the debian-ppc64 build failure has now been solved, the intent of the bunsenweb tool is to help figure out test result differences between builders. I have added Frank to the CC who can explain better than me. We'll also have a BoF at the GNU Tools Cauldron for suggestions on how the improve it and the integration with other sourceware services [*]. So the table above is all the builds that bunsen knows about for glibc-debian-ppc64. Note that currently we only have one ppc64[be] worker that does glibc builds. You can select a couple of builds and compare them. Pick the failing one, which was 498f51, and the last succeeding one. And compare the results, configs, etc. There are a couple of ways to explore the diffs. One is by looking at the buildbot "upload to bunsen" step and select that URL (this really should be improved to make this easier to find). This then gives you different "clusters" of similar (but possible different) other builds to compare to. e.g. look at https://builder.sourceware.org/testrun/498f51f327afdd7030516455b709a31a0038b432 Another is to look at all results for a particular builder (as above) or to look at all the glibc builds using the (sql) search form. e.g. https://builder.sourceware.org/testruns/?has_keyvalue_like_k=testrun.git_describe&has_keyvalue_like_v=%25glibc%25 And then pick various results by hand and hit "diff". The diffs are split up between groups of results, like the glibc test results or autoconf logs, etc. Clicking through will give you the actual config.log, the results.out files, etc. Cheers, Mark [*] https://gcc.gnu.org/wiki/cauldron2022#cauldron2022talks.Sourceware_GNU_Toolchain_Infrastructure_and_beyond