From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAD_ENC_HEADER,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E70301F463 for ; Thu, 12 Sep 2019 14:14:52 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=I9yzhYU3uy4fert/ rsdJRXRbcA9OVpSVLaltaAPW2viWUH2DZrW/k9yb/yEyxgd2DBax+RbwUN/ZblRu 6+yPaxZ6GYvPzh42FhFU6K+MMo4ynMAG4+3mpR7sMH0cvOfAlGZZkaIugIwJNcGQ 40Z39VRp+6NTiqjTN4tAHyyD4gI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=MsWZUNwT2IE4JQilkCOMgh oMmLI=; b=ahuFZ7gKfETy3SB6esqI6J7VXNSRLRPl8atYLpoTjrJWhbodobzTyO Gpz0/k8HPO4hWc3PNR6bWLDNkiCXxndveJI4e8O51z5808GPz+LGhNAYGk435FgU vetsdoLAxs/Jw2OQQbMKy5YOGNzYBBrdPmuVaG59qWI14rj4t2ahA= Received: (qmail 107402 invoked by alias); 12 Sep 2019 14:14:50 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 107393 invoked by uid 89); 12 Sep 2019 14:14:50 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com Subject: Re: [PATCH] Speedup nptl/tst-rwlock19. To: Stefan Liebler , GNU C Library References: <63377b64-9da9-0588-e3d5-92a4f1a1e6d0@linux.ibm.com> From: Carlos O'Donell Message-ID: Date: Thu, 12 Sep 2019 10:14:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <63377b64-9da9-0588-e3d5-92a4f1a1e6d0@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 9/12/19 8:16 AM, Stefan Liebler wrote: > Hi, > > the test creates 15 threads which are trying 5000x to pthread_rwlock_rdlock > a modified lock where the number of readers is set to max - 5.  If locked > successfully, it sleeps for 1ms. > > The test succeeds if the lock was rdlock'ed successfully for at least > one time and it has failed at least once with EAGAIN and the > number of readers needs to be max - 5 again after all threads have joined. > > The test is currently running for 5 seconds.  Thus this patch reduces > the READTRIES from 5000 to 100 and is increasing the DELAY from 1ms to 5ms. > Then the test runs for roughly 0.5 seconds. Why do we need to limit the retries? The point of the test is to run until we see a successful lock, and a failed lock with EAGAIN. It should be possible to make this test robust and so that when we run it on slower i686 it should jus run until it sees the events it needs to see, or fail from timeout (indicating a problem). I'm worried that by limiting the retires we'll see failures on slower or loaded hardware in the lab, and then we'll have to go back and bump up the retries again. The optimal test in my mind is: - Run forever. - Look for events of interest. - Exit success when those events are seen. - Fail if we timeout. -- Cheers, Carlos.