From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127547 invoked by alias); 28 Apr 2015 21:50:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 127529 invoked by uid 89); 28 Apr 2015 21:50:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f50.google.com Received: from mail-oi0-f50.google.com (HELO mail-oi0-f50.google.com) (209.85.218.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 28 Apr 2015 21:50:36 +0000 Received: by oica37 with SMTP id a37so7587487oic.0 for ; Tue, 28 Apr 2015 14:50:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+3Mj7/zS36/1DZI+8xgSv/MaA8T2J1q9RpsLXo3b+z8=; b=Qxjqutfdymktlmgt2ulUCLkZJGpGAFX0twoXz/76z8SBRCV8faTH/ZpR5TGwt2QUA1 9EHRE/DpT24MNZYj2LJml3W9nQ7iLAVJqtS7HJKW6aGudXn77HQdBHKjeTbRxkK0lDYB MsOnfDmwUKp3uahAtlWKvZ5HcsEaEmYA3hX8s5oYxF4xNtzc4gSAJP2FpjPdTwU5j3KS 5nv/mh57YUMyOxEtgIjdAeVd1WrAdEq8Zx09i5Km+FqQVqGG2sLPty+H3+2QWkP1zwNu 8RhJAxvul1a/gGh2M/gNe4ZGio4YPc/ml4Tne/RNdzsSojwcCrb8TEb+BGNNHwrs3olD ESKw== X-Gm-Message-State: ALoCoQmk29dLvV+rCR9abT5s3OJrtMBsNWcqCdQPD83a6tV9ZiKZUtEE9gOAbiOebC/CfhsOOs9I MIME-Version: 1.0 X-Received: by 10.202.217.196 with SMTP id q187mr15468688oig.64.1430257834603; Tue, 28 Apr 2015 14:50:34 -0700 (PDT) Received: by 10.182.89.99 with HTTP; Tue, 28 Apr 2015 14:50:34 -0700 (PDT) In-Reply-To: <21823.45051.20019.326313@ruffy2.mtv.corp.google.com> References: <1429267521-21047-1-git-send-email-palves@redhat.com> <1429267521-21047-2-git-send-email-palves@redhat.com> <5537DEDD.5000103@redhat.com> <21823.45051.20019.326313@ruffy2.mtv.corp.google.com> Date: Wed, 29 Apr 2015 04:56:00 -0000 Message-ID: Subject: Re: [PATCH v3 01/17] Fix and test "checkpoint" in non-stop mode From: Doug Evans To: Pedro Alves Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01058.txt.bz2 On Tue, Apr 28, 2015 at 9:06 AM, Doug Evans wrote: > The axis on which I'm worried is whether this will turn out to be > 1 extra file or 1000. One extra file per test doesn't scale. > And trying to reign in 100 files, or whatever the threshold is > before it's clear that we need to change course, will be more > painful than having a table-driven approach that can be simple > now and still grow as needed. (*1) > > Another way to go would be really just have 1 extra file (or 1 extra > file per gdb.foo subdir or some such), and this file > documents all the tests intended to be run in different modes > within one "make check". One could even extend > this to be more than just all-stop/non-stop. > > Another way, though, is to have two "make check" runs: > One with all-stop and one with non-stop. > Tests that can't handle one or the other should be marked > as such anyway. How a test chooses to handle the choice > is an internal implementation decision regardless of which > route is chosen. Yeah, running some tests twice this way > won't enhance coverage (e.g., no point in running help.exp in > all-stop and non-stop), but we should be almost within epsilon > of being able to do this today (I know I've done it in the past), > and complete test runs only take a few minutes on any reasonably > beefy system (at least they do on mine). > > (*1): A hybrid table driven approach could be to (effectively) > run the test twice using whatever mechanism that running > "make check" twice would use. This way only the specified > set of tests would be run twice (instead of running the whole testsuite > twice), and one can still manually run individual tests in whatever > mode (all-stop/non-stop/whatever) one chooses. > > My counter-proposal would be to see the extent to which we can > just run the testsuite in all-stop and non-stop, and do that for now > while we work towards something that scales better. > Someone could get a basic table-driven scheme going in a day. [Sorry for the resend ... cursed text/html.] Another thought was that if this is just a one-off and you're manually splitting up non-stop from all-stop to maintain parallelizability of the tests then I might not mind the new file. IOW, tests that want to handle both all-stop and non-stop in one "make check" can do so in one file. Any loss in parallelization is probably minimal (modulo really big tests). Btw, checkpoint.exp completes in 9 seconds on my system. I suspect doubling that and doing both all-stop and non-stop in the one file won't increase "make check-parallel" noticeably.