emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-bug-tracker] bug#8848: closed ([PATCH] tests: avoid sort-spinlock


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#8848: closed ([PATCH] tests: avoid sort-spinlock-abuse false positive under heavy load)
Date: Fri, 22 Jul 2011 21:53:02 +0000

Your message dated Fri, 22 Jul 2011 23:52:48 +0200
with message-id <address@hidden>
and subject line Re: bug#8848: [PATCH] tests: avoid sort-spinlock-abuse false 
positive under heavy load
has caused the GNU bug report #8848,
regarding [PATCH] tests: avoid sort-spinlock-abuse false positive under heavy 
load
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
8848: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8848
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [PATCH] tests: avoid sort-spinlock-abuse false positive under heavy load Date: Mon, 13 Jun 2011 12:17:26 +0200
When building with -j25 on a 6/12-core system, this test would
fail about half of the time.  With the patch below, it passed
"make -j25 check" 30 times in a row.

>From d40c2045707bad96e7a8caff2283b537163b8919 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Mon, 13 Jun 2011 11:05:49 +0200
Subject: [PATCH] tests: avoid sort-spinlock-abuse false positive under
 heavy load

* tests/misc/sort-spinlock-abuse: This test would frequently fail
when run on a system under heavy load.  Increase duration and limit.
---
 tests/misc/sort-spinlock-abuse |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tests/misc/sort-spinlock-abuse b/tests/misc/sort-spinlock-abuse
index b5ca30f..fc9612c 100755
--- a/tests/misc/sort-spinlock-abuse
+++ b/tests/misc/sort-spinlock-abuse
@@ -26,13 +26,14 @@ grep '^#define HAVE_PTHREAD_T 1' "$CONFIG_HEADER" > 
/dev/null ||
 seq 100000 > in || framework_failure_
 mkfifo_or_skip_ fifo

-# Arrange for sort to require 5.0+ seconds of wall-clock time,
+# Arrange for sort to require 8.0+ seconds of wall-clock time,
 # while actually using far less than 1 second of CPU time.
-(for i in $(seq 50); do read line; echo $i; sleep .1; done
+(for i in $(seq 80); do read line; echo $i; sleep .1; done
   cat > /dev/null) < fifo &

-# Limit CPU time to 1 second
-ulimit -t 1
+# However, under heavy load, it can easily take more than
+# one second of CPU time, so set a permissive limit:
+ulimit -t 7
 sort --parallel=2 in > fifo || fail=1

 Exit $fail
--
1.7.6.rc0.293.g40857



--- End Message ---
--- Begin Message --- Subject: Re: bug#8848: [PATCH] tests: avoid sort-spinlock-abuse false positive under heavy load Date: Fri, 22 Jul 2011 23:52:48 +0200
Jim Meyering wrote:
> When building with -j25 on a 6/12-core system, this test would
> fail about half of the time.  With the patch below, it passed
> "make -j25 check" 30 times in a row.
>
>>From d40c2045707bad96e7a8caff2283b537163b8919 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <address@hidden>
> Date: Mon, 13 Jun 2011 11:05:49 +0200
> Subject: [PATCH] tests: avoid sort-spinlock-abuse false positive under
>  heavy load
>
> * tests/misc/sort-spinlock-abuse: This test would frequently fail
> when run on a system under heavy load.  Increase duration and limit.
> ---
>  tests/misc/sort-spinlock-abuse |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/tests/misc/sort-spinlock-abuse b/tests/misc/sort-spinlock-abuse
> index b5ca30f..fc9612c 100755
> --- a/tests/misc/sort-spinlock-abuse
> +++ b/tests/misc/sort-spinlock-abuse
> @@ -26,13 +26,14 @@ grep '^#define HAVE_PTHREAD_T 1' "$CONFIG_HEADER" > 
> /dev/null ||
>  seq 100000 > in || framework_failure_
>  mkfifo_or_skip_ fifo
>
> -# Arrange for sort to require 5.0+ seconds of wall-clock time,
> +# Arrange for sort to require 8.0+ seconds of wall-clock time,

This was pushed, and subsequently the entire test
was mostly-disabled as "very expensive", so I'm closing this.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]