code review 12406043: runtime: disable dynamic priority boosting on windows

runtime: disable dynamic priority boosting on windows
Windows dynamic priority boosting assumes that a process has different types
of dedicated threads -- GUI, IO, computational, etc. Go processes use
equivalent threads that all do a mix of GUI, IO, computations, etc.
In such context dynamic priority boosting does nothing but harm, so turn it off.
In particular, if 2 goroutines do heavy IO on a server uniprocessor machine,
windows rejects to schedule timer thread for 2+ seconds when priority boosting is enabled.
Fixes issue 5971.

[dvyukov, 2013-08-03 10:29:37]

Hello alex.brainman@gmail.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://dvyukov%40google.com@code.google.com/p/go/

[dvyukov, 2013-08-03 10:30:19]

Alex, I've tested this on the 64-bit builder. Please test this on your other
machine that experienced the problem.

[brainman, 2013-08-03 10:36:33]

On 2013/08/03 10:30:19, dvyukov wrote:
> Alex, I've tested this on the 64-bit builder. Please test this on your other
> machine that experienced the problem.

Will do, but not until Monday. Thanks for your help.

Alex

[brainman, 2013-08-04 02:36:08]

LGTM

Works fine here. Thank you.

Alex

[dvyukov, 2013-08-04 10:09:44]

*** Submitted as https://code.google.com/p/go/source/detail?r=6423f26d0193 ***

runtime: disable dynamic priority boosting on windows
Windows dynamic priority boosting assumes that a process has different types
of dedicated threads -- GUI, IO, computational, etc. Go processes use
equivalent threads that all do a mix of GUI, IO, computations, etc.
In such context dynamic priority boosting does nothing but harm, so turn it off.
In particular, if 2 goroutines do heavy IO on a server uniprocessor machine,
windows rejects to schedule timer thread for 2+ seconds when priority boosting
is enabled.
Fixes issue 5971.

R=alex.brainman
CC=golang-dev
https://codereview.appspot.com/12406043

[dvyukov, 2013-08-04 10:40:47]

On Sun, Aug 4, 2013 at 6:36 AM,  <alex.brainman@gmail.com> wrote:
> LGTM
>
> Works fine here. Thank you.


Great
Builders are happy as well

There is a small remaining issue with accept that I will address, but
other than that netpoll transition can be considered successful. This
opens doors for other improvements.

[brainman, 2013-08-04 23:32:23]

windows-386 runtime test now takes longer and build breaks. Should we increase
timeout? Should I investigate to see what takes longer?

Alex

[dvyukov, 2013-08-05 08:56:13]

On Mon, Aug 5, 2013 at 3:32 AM,  <alex.brainman@gmail.com> wrote:
> windows-386 runtime test now takes longer and build breaks. Should we
> increase timeout? Should I investigate to see what takes longer?

If you can quickly identify what become slower, it would be great.
Increasing timeout sounds good to me.
If there is some test that takes particularly long, we can reduce
number of iterations in short mode.
W/o some kind of performance dashboard, it's difficult to say whether
we have some real slowdown on real programs, or just make synthetic
tests slower or add more tests...

[brainman, 2013-08-06 05:21:26]

On 2013/08/05 08:56:13, dvyukov wrote:
> ...
> If you can quickly identify what become slower, it would be great.

I have created https://code.google.com/p/go/issues/detail?id=6054.

> Increasing timeout sounds good to me.
> If there is some test that takes particularly long, we can reduce
> number of iterations in short mode.

Please, look at the issue, then we can decide what to do.

Thank you.

Alex

[brainman, 2013-08-22 00:52:22]

Dmitriy,

I decided to investigate all recent windows-386 failures, and I think this
change has the opposite effect on our windows-386 builder now.

I have changed test (just for better output)

diff --git a/src/pkg/net/timeout_test.go b/src/pkg/net/timeout_test.go
--- a/src/pkg/net/timeout_test.go
+++ b/src/pkg/net/timeout_test.go
@@ -480,7 +480,6 @@
 		}
 		for run := 0; run < numRuns; run++ {
 			name := fmt.Sprintf("%v run %d/%d", timeout, run+1, numRuns)
-			t.Log(name)
 
 			c, err := Dial("tcp", ln.Addr().String())
 			if err != nil {
@@ -500,7 +499,7 @@
 			select {
 			case res := <-clientc:
 				if isTimeout(res.err) {
-					t.Logf("for %v, good client timeout after %v, reading %d bytes", name,
res.d, res.n)
+					t.Logf("want=%v have=%v", timeout, res.d)
 				} else {
 					t.Fatalf("for %v: client Copy = %d, %v (want timeout)", name, res.n,
res.err)
 				}
@@ -509,8 +508,7 @@
 			}
 
 			select {
-			case res := <-servec:
-				t.Logf("for %v: server in %v wrote %d, %v", name, res.d, res.n, res.err)
+			case <-servec:
 			case err := <-acceptc:
 				t.Fatalf("for %v: server Accept = %v", name, err)
 			case <-time.After(tooLong):

and (running on windows-386 builder) It outputs this

=== RUN TestVariousDeadlines4Proc
--- PASS: TestVariousDeadlines4Proc (38.53 seconds)
	timeout_test.go:502: want=1ns have=2ms
	timeout_test.go:502: want=1ns have=1ms
	timeout_test.go:502: want=1ns have=1ms
	timeout_test.go:502: want=2ns have=656ms
	timeout_test.go:502: want=2ns have=1.867s
	timeout_test.go:502: want=2ns have=1.741s
	timeout_test.go:502: want=5ns have=415ms
	timeout_test.go:502: want=5ns have=660ms
	timeout_test.go:502: want=5ns have=434ms
	timeout_test.go:502: want=50ns have=743ms
	timeout_test.go:502: want=50ns have=740ms
	timeout_test.go:502: want=50ns have=878ms
	timeout_test.go:502: want=100ns have=686ms
	timeout_test.go:502: want=100ns have=713ms
	timeout_test.go:502: want=100ns have=476ms
	timeout_test.go:502: want=200ns have=663ms
	timeout_test.go:502: want=200ns have=540ms
	timeout_test.go:502: want=200ns have=779ms
	timeout_test.go:502: want=500ns have=630ms
	timeout_test.go:502: want=500ns have=840ms
	timeout_test.go:502: want=500ns have=631ms
	timeout_test.go:502: want=750ns have=420ms
	timeout_test.go:502: want=750ns have=689ms
	timeout_test.go:502: want=750ns have=749ms
	timeout_test.go:502: want=1us have=570ms
	timeout_test.go:502: want=1us have=688ms
	timeout_test.go:502: want=1us have=569ms
	timeout_test.go:502: want=5us have=655ms
	timeout_test.go:502: want=5us have=663ms
	timeout_test.go:502: want=5us have=502ms
	timeout_test.go:502: want=25us have=547ms
	timeout_test.go:502: want=25us have=629ms
	timeout_test.go:502: want=25us have=351ms
	timeout_test.go:502: want=250us have=818ms
	timeout_test.go:502: want=250us have=509ms
	timeout_test.go:502: want=250us have=779ms
	timeout_test.go:502: want=500us have=690ms
	timeout_test.go:502: want=500us have=786ms
	timeout_test.go:502: want=500us have=488ms
	timeout_test.go:502: want=1ms have=833ms
	timeout_test.go:502: want=1ms have=725ms
	timeout_test.go:502: want=1ms have=766ms
	timeout_test.go:502: want=5ms have=390ms
	timeout_test.go:502: want=5ms have=571ms
	timeout_test.go:502: want=5ms have=350ms
	timeout_test.go:502: want=100ms have=721ms
	timeout_test.go:502: want=100ms have=488ms
	timeout_test.go:502: want=100ms have=597ms
	timeout_test.go:502: want=250ms have=573ms
	timeout_test.go:502: want=250ms have=655ms
	timeout_test.go:502: want=250ms have=408ms
	timeout_test.go:502: want=500ms have=734ms
	timeout_test.go:502: want=500ms have=840ms
	timeout_test.go:502: want=500ms have=630ms
	timeout_test.go:502: want=1s have=1.56s
	timeout_test.go:502: want=1s have=1.17s
	timeout_test.go:502: want=1s have=1.286s
PASS
ok  	net	38.817s

See how real test time is much longer then "want". Then I reverted
SetProcessPriorityBoost change
			
diff --git a/src/pkg/runtime/os_windows.c b/src/pkg/runtime/os_windows.c
--- a/src/pkg/runtime/os_windows.c
+++ b/src/pkg/runtime/os_windows.c
@@ -84,7 +84,6 @@
 runtime·osinit(void)
 {
 	void *kernel32;
-	void *SetProcessPriorityBoost;
 
 	// -1 = current process, -2 = current thread
 	runtime·stdcall(runtime·DuplicateHandle, 7,
@@ -96,13 +95,6 @@
 
 	kernel32 = runtime·stdcall(runtime·LoadLibraryA, 1, "kernel32.dll");
 	if(kernel32 != nil) {
-		// Windows dynamic priority boosting assumes that a process has different
types
-		// of dedicated threads -- GUI, IO, computational, etc. Go processes use
-		// equivalent threads that all do a mix of GUI, IO, computations, etc.
-		// In such context dynamic priority boosting does nothing but harm, so we
turn it off.
-		SetProcessPriorityBoost = runtime·stdcall(runtime·GetProcAddress, 2,
kernel32, "SetProcessPriorityBoost");
-		if(SetProcessPriorityBoost != nil)  // supported since Windows XP
-			runtime·stdcall(SetProcessPriorityBoost, 2, (uintptr)-1, (uintptr)1);
 		runtime·GetQueuedCompletionStatusEx = runtime·stdcall(runtime·GetProcAddress,
2, kernel32, "GetQueuedCompletionStatusEx");
 	}
 }

and running same test gives

=== RUN TestVariousDeadlines4Proc
--- PASS: TestVariousDeadlines4Proc (6.89 seconds)
	timeout_test.go:502: want=1ns have=1ms
	timeout_test.go:502: want=1ns have=1ms
	timeout_test.go:502: want=1ns have=1ms
	timeout_test.go:502: want=2ns have=1ms
	timeout_test.go:502: want=2ns have=1ms
	timeout_test.go:502: want=2ns have=1ms
	timeout_test.go:502: want=5ns have=1ms
	timeout_test.go:502: want=5ns have=1ms
	timeout_test.go:502: want=5ns have=1ms
	timeout_test.go:502: want=50ns have=1ms
	timeout_test.go:502: want=50ns have=1ms
	timeout_test.go:502: want=50ns have=1ms
	timeout_test.go:502: want=100ns have=1ms
	timeout_test.go:502: want=100ns have=1ms
	timeout_test.go:502: want=100ns have=1ms
	timeout_test.go:502: want=200ns have=1ms
	timeout_test.go:502: want=200ns have=1ms
	timeout_test.go:502: want=200ns have=1ms
	timeout_test.go:502: want=500ns have=1ms
	timeout_test.go:502: want=500ns have=1ms
	timeout_test.go:502: want=500ns have=1ms
	timeout_test.go:502: want=750ns have=1ms
	timeout_test.go:502: want=750ns have=1ms
	timeout_test.go:502: want=750ns have=1ms
	timeout_test.go:502: want=1us have=1ms
	timeout_test.go:502: want=1us have=1ms
	timeout_test.go:502: want=1us have=1ms
	timeout_test.go:502: want=5us have=1ms
	timeout_test.go:502: want=5us have=1ms
	timeout_test.go:502: want=5us have=1ms
	timeout_test.go:502: want=25us have=1ms
	timeout_test.go:502: want=25us have=1ms
	timeout_test.go:502: want=25us have=1ms
	timeout_test.go:502: want=250us have=1ms
	timeout_test.go:502: want=250us have=1ms
	timeout_test.go:502: want=250us have=1ms
	timeout_test.go:502: want=500us have=1ms
	timeout_test.go:502: want=500us have=1ms
	timeout_test.go:502: want=500us have=1ms
	timeout_test.go:502: want=1ms have=1ms
	timeout_test.go:502: want=1ms have=1ms
	timeout_test.go:502: want=1ms have=1ms
	timeout_test.go:502: want=5ms have=64ms
	timeout_test.go:502: want=5ms have=5ms
	timeout_test.go:502: want=5ms have=5ms
	timeout_test.go:502: want=100ms have=139ms
	timeout_test.go:502: want=100ms have=119ms
	timeout_test.go:502: want=100ms have=149ms
	timeout_test.go:502: want=250ms have=269ms
	timeout_test.go:502: want=250ms have=268ms
	timeout_test.go:502: want=250ms have=299ms
	timeout_test.go:502: want=500ms have=500ms
	timeout_test.go:502: want=500ms have=549ms
	timeout_test.go:502: want=500ms have=538ms
	timeout_test.go:502: want=1s have=1.001s
	timeout_test.go:502: want=1s have=1.039s
	timeout_test.go:502: want=1s have=1.046s
PASS
ok  	net	7.416s

The test becomes much more consistent now. I am not sure what to do?

Alex

[dvyukov, 2013-08-22 01:04:21]

On Thu, Aug 22, 2013 at 4:52 AM,  <alex.brainman@gmail.com> wrote:
> Dmitriy,
>
> I decided to investigate all recent windows-386 failures, and I think
> this change has the opposite effect on our windows-386 builder now.
>
> I have changed test (just for better output)
>
> diff --git a/src/pkg/net/timeout_test.go b/src/pkg/net/timeout_test.go
> --- a/src/pkg/net/timeout_test.go
> +++ b/src/pkg/net/timeout_test.go
> @@ -480,7 +480,6 @@
>                 }
>                 for run := 0; run < numRuns; run++ {
>                         name := fmt.Sprintf("%v run %d/%d", timeout, run+1,
> numRuns)
> -                       t.Log(name)
>
>                         c, err := Dial("tcp", ln.Addr().String())
>                         if err != nil {
> @@ -500,7 +499,7 @@
>                         select {
>                         case res := <-clientc:
>                                 if isTimeout(res.err) {
> -                                       t.Logf("for %v, good client timeout
> after %v, reading %d bytes",
> name, res.d, res.n)
> +                                       t.Logf("want=%v have=%v", timeout,
> res.d)
>                                 } else {
>                                         t.Fatalf("for %v: client Copy = %d,
> %v (want timeout)", name,
> res.n, res.err)
>                                 }
> @@ -509,8 +508,7 @@
>                         }
>
>                         select {
> -                       case res := <-servec:
> -                               t.Logf("for %v: server in %v wrote %d, %v",
> name, res.d, res.n,
> res.err)
> +                       case <-servec:
>                         case err := <-acceptc:
>                                 t.Fatalf("for %v: server Accept = %v", name,
> err)
>                         case <-time.After(tooLong):
>
> and (running on windows-386 builder) It outputs this
>
> === RUN TestVariousDeadlines4Proc
> --- PASS: TestVariousDeadlines4Proc (38.53 seconds)
>         timeout_test.go:502: want=1ns have=2ms
>         timeout_test.go:502: want=1ns have=1ms
>         timeout_test.go:502: want=1ns have=1ms
>         timeout_test.go:502: want=2ns have=656ms
>         timeout_test.go:502: want=2ns have=1.867s
>         timeout_test.go:502: want=2ns have=1.741s
>         timeout_test.go:502: want=5ns have=415ms
>         timeout_test.go:502: want=5ns have=660ms
>         timeout_test.go:502: want=5ns have=434ms
>         timeout_test.go:502: want=50ns have=743ms
>         timeout_test.go:502: want=50ns have=740ms
>         timeout_test.go:502: want=50ns have=878ms
>         timeout_test.go:502: want=100ns have=686ms
>         timeout_test.go:502: want=100ns have=713ms
>         timeout_test.go:502: want=100ns have=476ms
>         timeout_test.go:502: want=200ns have=663ms
>         timeout_test.go:502: want=200ns have=540ms
>         timeout_test.go:502: want=200ns have=779ms
>         timeout_test.go:502: want=500ns have=630ms
>         timeout_test.go:502: want=500ns have=840ms
>         timeout_test.go:502: want=500ns have=631ms
>         timeout_test.go:502: want=750ns have=420ms
>         timeout_test.go:502: want=750ns have=689ms
>         timeout_test.go:502: want=750ns have=749ms
>         timeout_test.go:502: want=1us have=570ms
>         timeout_test.go:502: want=1us have=688ms
>         timeout_test.go:502: want=1us have=569ms
>         timeout_test.go:502: want=5us have=655ms
>         timeout_test.go:502: want=5us have=663ms
>         timeout_test.go:502: want=5us have=502ms
>         timeout_test.go:502: want=25us have=547ms
>         timeout_test.go:502: want=25us have=629ms
>         timeout_test.go:502: want=25us have=351ms
>         timeout_test.go:502: want=250us have=818ms
>         timeout_test.go:502: want=250us have=509ms
>         timeout_test.go:502: want=250us have=779ms
>         timeout_test.go:502: want=500us have=690ms
>         timeout_test.go:502: want=500us have=786ms
>         timeout_test.go:502: want=500us have=488ms
>         timeout_test.go:502: want=1ms have=833ms
>         timeout_test.go:502: want=1ms have=725ms
>         timeout_test.go:502: want=1ms have=766ms
>         timeout_test.go:502: want=5ms have=390ms
>         timeout_test.go:502: want=5ms have=571ms
>         timeout_test.go:502: want=5ms have=350ms
>         timeout_test.go:502: want=100ms have=721ms
>         timeout_test.go:502: want=100ms have=488ms
>         timeout_test.go:502: want=100ms have=597ms
>         timeout_test.go:502: want=250ms have=573ms
>         timeout_test.go:502: want=250ms have=655ms
>         timeout_test.go:502: want=250ms have=408ms
>         timeout_test.go:502: want=500ms have=734ms
>         timeout_test.go:502: want=500ms have=840ms
>         timeout_test.go:502: want=500ms have=630ms
>         timeout_test.go:502: want=1s have=1.56s
>         timeout_test.go:502: want=1s have=1.17s
>         timeout_test.go:502: want=1s have=1.286s
> PASS
> ok      net     38.817s
>
> See how real test time is much longer then "want". Then I reverted
> SetProcessPriorityBoost change
>
> diff --git a/src/pkg/runtime/os_windows.c b/src/pkg/runtime/os_windows.c
> --- a/src/pkg/runtime/os_windows.c
> +++ b/src/pkg/runtime/os_windows.c
> @@ -84,7 +84,6 @@
>  runtime·osinit(void)
>  {
>         void *kernel32;
> -       void *SetProcessPriorityBoost;
>
>         // -1 = current process, -2 = current thread
>         runtime·stdcall(runtime·DuplicateHandle, 7,
> @@ -96,13 +95,6 @@
>
>         kernel32 = runtime·stdcall(runtime·LoadLibraryA, 1, "kernel32.dll");
>         if(kernel32 != nil) {
> -               // Windows dynamic priority boosting assumes that a process
> has
> different types
> -               // of dedicated threads -- GUI, IO, computational, etc. Go
> processes
> use
> -               // equivalent threads that all do a mix of GUI, IO,
> computations,
> etc.
> -               // In such context dynamic priority boosting does nothing
> but harm,
> so we turn it off.
> -               SetProcessPriorityBoost =
> runtime·stdcall(runtime·GetProcAddress, 2,
> kernel32, "SetProcessPriorityBoost");
> -               if(SetProcessPriorityBoost != nil)  // supported since
> Windows XP
> -                       runtime·stdcall(SetProcessPriorityBoost, 2,
> (uintptr)-1,
> (uintptr)1);
>                 runtime·GetQueuedCompletionStatusEx =
> runtime·stdcall(runtime·GetProcAddress, 2, kernel32,
> "GetQueuedCompletionStatusEx");
>         }
>  }
>
> and running same test gives
>
> === RUN TestVariousDeadlines4Proc
> --- PASS: TestVariousDeadlines4Proc (6.89 seconds)
>         timeout_test.go:502: want=1ns have=1ms
>         timeout_test.go:502: want=1ns have=1ms
>         timeout_test.go:502: want=1ns have=1ms
>         timeout_test.go:502: want=2ns have=1ms
>         timeout_test.go:502: want=2ns have=1ms
>         timeout_test.go:502: want=2ns have=1ms
>         timeout_test.go:502: want=5ns have=1ms
>         timeout_test.go:502: want=5ns have=1ms
>         timeout_test.go:502: want=5ns have=1ms
>         timeout_test.go:502: want=50ns have=1ms
>         timeout_test.go:502: want=50ns have=1ms
>         timeout_test.go:502: want=50ns have=1ms
>         timeout_test.go:502: want=100ns have=1ms
>         timeout_test.go:502: want=100ns have=1ms
>         timeout_test.go:502: want=100ns have=1ms
>         timeout_test.go:502: want=200ns have=1ms
>         timeout_test.go:502: want=200ns have=1ms
>         timeout_test.go:502: want=200ns have=1ms
>         timeout_test.go:502: want=500ns have=1ms
>         timeout_test.go:502: want=500ns have=1ms
>         timeout_test.go:502: want=500ns have=1ms
>         timeout_test.go:502: want=750ns have=1ms
>         timeout_test.go:502: want=750ns have=1ms
>         timeout_test.go:502: want=750ns have=1ms
>         timeout_test.go:502: want=1us have=1ms
>         timeout_test.go:502: want=1us have=1ms
>         timeout_test.go:502: want=1us have=1ms
>         timeout_test.go:502: want=5us have=1ms
>         timeout_test.go:502: want=5us have=1ms
>         timeout_test.go:502: want=5us have=1ms
>         timeout_test.go:502: want=25us have=1ms
>         timeout_test.go:502: want=25us have=1ms
>         timeout_test.go:502: want=25us have=1ms
>         timeout_test.go:502: want=250us have=1ms
>         timeout_test.go:502: want=250us have=1ms
>         timeout_test.go:502: want=250us have=1ms
>         timeout_test.go:502: want=500us have=1ms
>         timeout_test.go:502: want=500us have=1ms
>         timeout_test.go:502: want=500us have=1ms
>         timeout_test.go:502: want=1ms have=1ms
>         timeout_test.go:502: want=1ms have=1ms
>         timeout_test.go:502: want=1ms have=1ms
>         timeout_test.go:502: want=5ms have=64ms
>         timeout_test.go:502: want=5ms have=5ms
>         timeout_test.go:502: want=5ms have=5ms
>         timeout_test.go:502: want=100ms have=139ms
>         timeout_test.go:502: want=100ms have=119ms
>         timeout_test.go:502: want=100ms have=149ms
>         timeout_test.go:502: want=250ms have=269ms
>         timeout_test.go:502: want=250ms have=268ms
>         timeout_test.go:502: want=250ms have=299ms
>         timeout_test.go:502: want=500ms have=500ms
>         timeout_test.go:502: want=500ms have=549ms
>         timeout_test.go:502: want=500ms have=538ms
>         timeout_test.go:502: want=1s have=1.001s
>         timeout_test.go:502: want=1s have=1.039s
>         timeout_test.go:502: want=1s have=1.046s
> PASS
> ok      net     7.416s
>
> The test becomes much more consistent now. I am not sure what to do?


Humm...

I observed exactly opposite effect on the 64-bit builder and my machine...

I can't understand how dynamic priority boosting can do good thing for
Go process. It looks like it boosted the timer thread in your case.
But this should not happen, and must be pure coincidence.

This test is quite weird as well. It tries to send and receive an
infinite stream of data with infinite speed. This is not a normal
situation. I don't want to complicate implementation to make weird
synthetic test happy. I suggest to update the test to make it more
realistic (or just increase the timeout).

[brainman, 2013-08-22 01:37:54]

On 2013/08/22 01:04:21, dvyukov wrote:
> 
> I observed exactly opposite effect on the 64-bit builder and my machine...

Yes, I can see the same here. But the facts do not lie. Feel free to jump on
windows-386 builder and investigate yourself. Would you like that?

> I can't understand how dynamic priority boosting can do good thing for
> Go process. It looks like it boosted the timer thread in your case.
> But this should not happen, and must be pure coincidence.

Well, this is all over my head :-), but I will take your word for it.

> This test is quite weird as well. It tries to send and receive an
> infinite stream of data with infinite speed. This is not a normal
> situation. I don't want to complicate implementation to make weird
> synthetic test happy. I suggest to update the test to make it more
> realistic (or just increase the timeout).

I agree with your sentiment. I think we spent too much effort trying to make all
these timeouts to work. I hope they are as useful. :-)

As to the test, I am not sure what to do. Should we just extend timeout to 5s or
10s or something on windows?

Alex

[dvyukov, 2013-08-22 10:47:59]

On 2013/08/22 01:37:54, brainman wrote:
> On 2013/08/22 01:04:21, dvyukov wrote:
> > 
> > I observed exactly opposite effect on the 64-bit builder and my machine...
> 
> Yes, I can see the same here. But the facts do not lie. Feel free to jump on
> windows-386 builder and investigate yourself. Would you like that?
> 
> > I can't understand how dynamic priority boosting can do good thing for
> > Go process. It looks like it boosted the timer thread in your case.
> > But this should not happen, and must be pure coincidence.
> 
> Well, this is all over my head :-), but I will take your word for it.
> 
> > This test is quite weird as well. It tries to send and receive an
> > infinite stream of data with infinite speed. This is not a normal
> > situation. I don't want to complicate implementation to make weird
> > synthetic test happy. I suggest to update the test to make it more
> > realistic (or just increase the timeout).
> 
> I agree with your sentiment. I think we spent too much effort trying to make
all
> these timeouts to work. I hope they are as useful. :-)
> 
> As to the test, I am not sure what to do. Should we just extend timeout to 5s
or
> 10s or something on windows?


Yeah, just bump timeout on windows to 5 seconds.
If you want to observe other weird effects of windows scheduler, try changing
scheduler type. That's Control Panel -> System -> Performance -> Prefer
Programs/Background services (don't remember the exact path, but somewhere
there).

[brainman, 2013-08-23 05:05:35]

On 2013/08/22 10:47:59, dvyukov wrote:
> 
> Yeah, just bump timeout on windows to 5 seconds.

https://codereview.appspot.com/12798045

> If you want to observe other weird effects of windows scheduler, try changing
> scheduler type. That's Control Panel -> System -> Performance -> Prefer
> Programs/Background services (don't remember the exact path, but somewhere
> there).

It is set to "Background services" on windows-386. I tried changing it but it
makes no difference on our test. I give up. :-)

Alex

[dvyukov, 2013-08-23 09:11:02]

On Fri, Aug 23, 2013 at 9:05 AM,  <alex.brainman@gmail.com> wrote:
> On 2013/08/22 10:47:59, dvyukov wrote:
>
>> Yeah, just bump timeout on windows to 5 seconds.
>
>
> https://codereview.appspot.com/12798045
>
>
>> If you want to observe other weird effects of windows scheduler, try
>
> changing
>>
>> scheduler type. That's Control Panel -> System -> Performance ->
>
> Prefer
>>
>> Programs/Background services (don't remember the exact path, but
>
> somewhere
>>
>> there).
>
>
> It is set to "Background services" on windows-386. I tried changing it
> but it makes no difference on our test. I give up. :-)


On 64-builder is was:
priority boosting+background scheduler = 2 sec test run time
no priority boosting+background scheduler = 400 ms test run time
no priority boosting+application scheduler = 60 ms test run time