From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id DAC743858D32 for ; Mon, 8 May 2023 17:52:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DAC743858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-50bd37ca954so51196373a12.0 for ; Mon, 08 May 2023 10:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683568341; x=1686160341; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=k7qg/UXJZRiRcfDpsibyrGyXiO6pKs4Nf76Ebt9+Quc=; b=FWzofYpKW+LX5tNV47Antc7fka9HywyYxl7UbElLTdyd0C1TOsFN9aGlVJnXm7pyPH tH9lkT+COgGDQ4laZY+WLWTIocfzoUlZ6LXik4xK5It0iyks03/jzcvi+n6RtwowML89 kQs6TuqPtoiM/v+fIQSKNQJg49mSl0Z5MCo4x2TpBL3H+qItILMWYKrjGMapbs/FKBWY r/CXFMz3Sq2sxdYD6TAp9p9bC71drXrGSGZ0tomywCOonGqChcGKNkMcRLNb0ZAPnmLU 37LLiZrbVMmoLSx2EB+3kEBES6YoLnFaB5IYQaJTPn8Njg0xR4Fo9+Ra9nmIhIyRhkGE hIUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683568341; x=1686160341; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k7qg/UXJZRiRcfDpsibyrGyXiO6pKs4Nf76Ebt9+Quc=; b=L/yh70abqtvDw+Ywrh9T709kkde2iQKftT6rHltSu52+82lHG5h7yxGlULisWNkKjj FKgM5h5XCleSMd+sRqL2pZCUBcS02iDwglnxb2e8S/NMcbCeRKEa2JYErT686l321eIA D/RPUHhX98SYyho0T/NFp30yOccD/9ruu2uViWFZY3LJyxl65Wmayd6NG0Dx84QDTghG uMogw82JyK/V3tdzOny8YmfulNlz2y02Me3y45U6kOF1BiKbgH4SD+xUdHV+6vWIehcE CDAInzT4BtUttGq+kpu3tL26ObV3b+R5yxUofjORsMGYF3RQXMpME6EmINXjJPSv438H 7yxQ== X-Gm-Message-State: AC+VfDw70XxLGVUBsubt7gcNq3nqvDKk1ek6sPjAdQz3fGSkHSn/auLv W+DkEAxayZULYsSRr98mK7w= X-Google-Smtp-Source: ACHHUZ5MyGAEQyEkrNC97vun/NES6yMKI8ixgJlsOMN7yZ+bz4fQyMgc1F8InGhO02ycn4ud5xNt8w== X-Received: by 2002:a05:6402:1d55:b0:506:bbf8:5152 with SMTP id dz21-20020a0564021d5500b00506bbf85152mr10989993edb.9.1683568341462; Mon, 08 May 2023 10:52:21 -0700 (PDT) Received: from nbbrfq (80-110-214-113.static.upcbusiness.at. [80.110.214.113]) by smtp.gmail.com with ESMTPSA id u4-20020a05640207c400b0050bd7267a5csm6336561edy.58.2023.05.08.10.52.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 May 2023 10:52:21 -0700 (PDT) Date: Mon, 8 May 2023 19:52:17 +0200 From: Bernhard Reutner-Fischer To: Thomas Schwinge Cc: Jakub Jelinek , Rainer Orth , , Tobias Burnus , Mike Stump , Jan Hubicka , Segher Boessenkool Subject: Re: Support parallel testing in libgomp, part I [PR66005] Message-ID: <20230508195217.4897009f@nbbrfq> In-Reply-To: <87bkivayue.fsf@euler.schwinge.homeip.net> References: <20150507113940.GI1751@tucnak.redhat.com> <87mw1fmpi5.fsf@schwinge.name> <87h6srb1iq.fsf@euler.schwinge.homeip.net> <20230506161545.2be3ffa6@nbbrfq> <87bkivayue.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 8 May 2023 12:42:33 +0200 Thomas Schwinge wrote: > >> +if [info exists ::env(GCC_RUNTEST_PARALLELIZE_DIR)] { > >> + load_file ../libgomp-test-support.exp > >> +} else { > >> + load_file libgomp-test-support.exp > >> +} =20 > > > > Do we have to re-read those? Otherwise this would be load_lib: =20 >=20 > Indeed there is some confusion there; conceptually the content of that > file has to be expected to vary per libgomp (multilib) build variant. > On the other hand, given the GCC target libraries testing setup, we're > running testing always via the default variant's build, so always read > the default variant's file. I agree that should get un-confused, however > it's a pre-existing issue that I suggest we tackle independently of this > mechanical change. Sure. One thing at a time. > > Some cosmetic nits. > > See Jakubs one_to_9999. =20 >=20 > Thanks. That got installed while I'd already finished my patch. ;-) > Note that the new 'one_to_9999' etc. is just the existing > 'check_p_numbers' etc. renamed and moved, as it now has a second use. > I'm happy to incorporate that into my changes -- if we agree that it > should also go into other GCC target libraries' parallel testing code: > libphobos, libstdc++-v3. Yes. Streamlining these can be done in follow-ups if the respective maintainers agree. > >> >> It is far from trivial though. > >> >> The point is that most of the OpenMP tests are parallelized with the > >> >> default OMP_NUM_THREADS, so running the tests in parallel oversubsc= ribes the > >> >> machine a lot, the higher number of hw threads the more. =20 [] > >> > the same time? For example, a new dg-* directive to run them wrapped > >> > through =C2=BBflock [libgomp/testsuite/serial.lock] [a.out]=C2=AB or= some such? =20 > > > > I think we all agree one that, yes. =20 >=20 > Conceptually, yes. However, given that my > "Support parallel testing in libgomp, part II [PR66005]" changes already > seem to enable a great amount of parallelism, occupying CPUs almost > fully, I'm not actually sure now if adding more parallelism via > tedious-to-maintain new dg-* directives is actually necessary/useful. As > long as libgomp testing now no longer is at the long tail end of overall > testing time, I'd rather keep it simple? If the testsuite runtime is fine with your part II as is then we should keep it as simple as possible. > >> > (Will again have the problem that DejaGnu doesn't provide infrastruc= ture > >> > to communicate environment variables to boards in remote testing.) = =20 > > > > Are you sure? I'm pretty confident that this worked fine at least at > > one point in the past for certain targets. =20 >=20 > For example, see the comments/references in recent > . oh, i think i had an rsh2 remote that uploaded $program.env and the rsh itself was something like $RSH $rsh_useropts $hostname sh -c 'test -r $program.env && . $program.env \\; $program $pargs \\; echo ... but that was ages ago and was properly implemented in the meantime, one would hope? Well, apparently not. PS: Back then I usually needed very different per-program env and not a single, static env. So for me it made no sense to have a set of default env and have tests add their own variables on-demand on top of the default. The situation in gcc might be the exact opposite? thanks,