mirror
/
go
mirror of https://github.com/golang/go.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
16,687 Commits 63 Branches 451 Tags 660 MiB
Commit Graph

21 Commits

Author SHA1 Message Date
Russ Cox 1184407f2a runtime: disable preemption test (fix build) 
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/10849043
 2013-07-01 18:10:03 -04:00
Dmitriy Vyukov 1e112cd59f runtime: preempt goroutines for GC 
The last patch for preemptive scheduler,
with this change stoptheworld issues preemption
requests every 100us.
Update #543.

R=golang-dev, daniel.morsing, rsc
CC=golang-dev
https://golang.org/cl/10264044
 2013-06-28 17:52:17 +04:00
Dmitriy Vyukov 7ebb187e8e undo CL 9776044 / 1e280889f997 
Failure on bot:
http://build.golang.org/log/f4c648906e1289ec2237c1d0880fb1a8b1852a08

««« original CL description
runtime: fix CPU underutilization
runtime.newproc/ready are deliberately sloppy about waking new M's,
they only ensure that there is at least 1 spinning M.
Currently to compensate for that, schedule() checks if the current P
has local work and there are no spinning M's, it wakes up another one.
It does not work if goroutines do not call schedule.
With this change a spinning M wakes up another M when it finds work to do.
It's also not ideal, but it fixes the underutilization.
A proper check would require to know the exact number of runnable G's,
but it's too expensive to maintain.
Fixes #5586.

R=rsc
TBR=rsc
CC=gobot, golang-dev
https://golang.org/cl/9776044
»»»

R=golang-dev
CC=golang-dev
https://golang.org/cl/10692043
 2013-06-27 21:03:35 +04:00
Dmitriy Vyukov 15a1c3d1e4 runtime: fix CPU underutilization 
runtime.newproc/ready are deliberately sloppy about waking new M's,
they only ensure that there is at least 1 spinning M.
Currently to compensate for that, schedule() checks if the current P
has local work and there are no spinning M's, it wakes up another one.
It does not work if goroutines do not call schedule.
With this change a spinning M wakes up another M when it finds work to do.
It's also not ideal, but it fixes the underutilization.
A proper check would require to know the exact number of runnable G's,
but it's too expensive to maintain.
Fixes #5586.

R=rsc
CC=gobot, golang-dev
https://golang.org/cl/9776044
 2013-06-27 20:52:12 +04:00
Dmitriy Vyukov 4bb491b12e runtime: improve scheduler fairness 
Currently global runqueue is starved if a group of goroutines
constantly respawn each other (local runqueue never becomes empty).
Fixes #5639.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/10042044
 2013-06-15 16:06:28 +04:00
Dmitriy Vyukov 38d4d3c66a runtime: refactor Syscall benchmark 
And add a benchmark where #goroutines>GOMAXPROCS,
because it's the most interesting case.
Current results on darwin/amd64, Intel Core 2 Duo 2.13 GHz, 2 cores:
BenchmarkSyscall	100000000	        56.0 ns/op
BenchmarkSyscall-2	50000000	        57.2 ns/op
BenchmarkSyscallWork	10000000	       635 ns/op
BenchmarkSyscallWork-2	10000000	       315 ns/op
BenchmarkSyscallExcess	 1000000	      2698 ns/op
BenchmarkSyscallExcess-2	 5000000	      1192 ns/op
BenchmarkSyscallExcessWork	 1000000	      2832 ns/op
BenchmarkSyscallExcessWork-2	 2000000	      1966 ns/op

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7415044
 2013-03-01 01:10:34 +02:00
Dmitriy Vyukov 72b09bd7ae runtime: add matrix multiplication benchmark 
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7431047
 2013-03-01 00:41:45 +02:00
Dmitriy Vyukov 353ce60f6e runtime: implement local work queues (in preparation for new scheduler) 
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7402047
 2013-02-23 08:48:02 +04:00
Dmitriy Vyukov a92e11a256 runtime: ensure forward progress of runtime.Gosched() for locked goroutines 
The removed code leads to the situation when M executes the same locked G again
and again.
This is https://golang.org/cl/7310096 but with return instead of break
in the nested switch.
Fixes #4820.

R=golang-dev, alex.brainman, rsc
CC=golang-dev
https://golang.org/cl/7304102
 2013-02-20 12:13:04 +04:00
Russ Cox 60526ca6d1 undo CL 7310096 / 59da6744d66d 
broke windows build

««« original CL description
runtime: ensure forward progress of runtime.Gosched() for locked goroutines
The removed code leads to the situation when M executes the same locked G again and again.
Fixes #4820.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7310096
»»»

TBR=dvyukov
CC=golang-dev
https://golang.org/cl/7343050
 2013-02-15 17:54:46 -05:00
Dmitriy Vyukov f87b7f67b2 runtime: ensure forward progress of runtime.Gosched() for locked goroutines 
The removed code leads to the situation when M executes the same locked G again and again.
Fixes #4820.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7310096
 2013-02-15 22:22:13 +04:00
Dmitriy Vyukov 6a828482fa runtime: add more tests for LockOSThread() 
Just test some additional paths through the scheduler.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7331044
 2013-02-15 00:02:12 +04:00
Dave Cheney 6a9e956f19 all: use t.Skip{,f} 
Replace various t.Log{,f} ; return checks with t.Skip{,f}.

R=golang-dev, n13m3y3r, bradfitz, adg, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/7193044
 2013-01-24 17:32:10 +11:00
Dmitriy Vyukov f82db7d9e4 runtime: less aggressive per-thread stack segment caching 
Introduce global stack segment cache and limit per-thread cache size.
This greatly reduces StackSys memory on workloads that create lots of threads.

benchmark                      old ns/op    new ns/op    delta
BenchmarkStackGrowth                 665          656   -1.35%
BenchmarkStackGrowth-2               333          328   -1.50%
BenchmarkStackGrowth-4               224          172  -23.21%
BenchmarkStackGrowth-8               124           91  -26.13%
BenchmarkStackGrowth-16               82           47  -41.94%
BenchmarkStackGrowth-32               73           40  -44.79%

BenchmarkStackGrowthDeep           97231        94391   -2.92%
BenchmarkStackGrowthDeep-2         47230        58562  +23.99%
BenchmarkStackGrowthDeep-4         24993        49356  +97.48%
BenchmarkStackGrowthDeep-8         15105        30072  +99.09%
BenchmarkStackGrowthDeep-16        10005        15623  +56.15%
BenchmarkStackGrowthDeep-32        12517        13069   +4.41%

TestStackMem#1,MB                  310          12       -96.13%
TestStackMem#2,MB                  296          14       -95.27%
TestStackMem#3,MB                  479          14       -97.08%

TestStackMem#1,sec                 3.22         2.26     -29.81%
TestStackMem#2,sec                 2.43         2.15     -11.52%
TestStackMem#3,sec                 2.50         2.38      -4.80%

R=sougou, no.smile.face, rsc
CC=golang-dev, msolomon
https://golang.org/cl/7029044
 2013-01-10 09:57:06 +04:00
Dmitriy Vyukov 5a5e698c8f runtime: add goroutine creation benchmark 
Current results on 2 core darwin/amd64:
BenchmarkGoroutineChain		351 ns/op
BenchmarkGoroutineChain-2	3840 ns/op
BenchmarkGoroutineChain-4	4040 ns/op
BenchmarkConcGoroutineChain	350 ns/op
BenchmarkConcGoroutineChain-2	875 ns/op
BenchmarkConcGoroutineChain-4	2027 ns/op

R=r, rsc
CC=golang-dev
https://golang.org/cl/6332054
 2012-06-27 21:57:49 +04:00
Russ Cox 025abd530e runtime: faster entersyscall, exitsyscall 
Uses atomic memory accesses to avoid the need to acquire
and release schedlock on fast paths.

benchmark                            old ns/op    new ns/op    delta
runtime_test.BenchmarkSyscall               73           31  -56.63%
runtime_test.BenchmarkSyscall-2            538           74  -86.23%
runtime_test.BenchmarkSyscall-3            508          103  -79.72%
runtime_test.BenchmarkSyscall-4            721           97  -86.52%
runtime_test.BenchmarkSyscallWork          920          873   -5.11%
runtime_test.BenchmarkSyscallWork-2        516          481   -6.78%
runtime_test.BenchmarkSyscallWork-3        550          343  -37.64%
runtime_test.BenchmarkSyscallWork-4        632          263  -58.39%

(Intel Core i7 L640 2.13 GHz-based Lenovo X201s)

Reduced a less artificial server benchmark
from 11.5r 12.0u 8.0s to 8.3r 9.1u 1.0s.

R=dvyukov, r, bradfitz, r, iant, iant
CC=golang-dev
https://golang.org/cl/4723042
 2011-07-19 11:01:17 -04:00
Dmitriy Vyukov c9152a8568 runtime: eliminate contention during stack allocation 
Standard-sized stack frames use plain malloc/free
instead of centralized lock-protected FixAlloc.
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows:
benchmark                                        old ns/op    new ns/op    delta
BenchmarkStackGrowth                               1045.00       949.00   -9.19%
BenchmarkStackGrowth-2                             3450.00       800.00  -76.81%
BenchmarkStackGrowth-4                             5076.00       513.00  -89.89%
BenchmarkStackGrowth-8                             7805.00       471.00  -93.97%
BenchmarkStackGrowth-16                           11751.00       321.00  -97.27%

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4657091
 2011-07-12 09:24:32 -07:00
Dmitriy Vyukov 91cc1e6b77 runtime: reset GOMAXPROCS during tests 
Fix the fact that the test leaves GOMAXPROCS=3
and a running goroutine behind.

R=golang-dev, rsc
CC=dvyukov, golang-dev
https://golang.org/cl/4517121
 2011-05-31 10:38:51 -04:00
Russ Cox 4f7fd3cb7f runtime: disable long test (fix arm build) 
TBR=r
CC=golang-dev
https://golang.org/cl/4449051
 2011-04-23 10:03:51 -04:00
Russ Cox 781df132f9 runtime: stop deadlock test properly (fix arm5 build) 
TBR=r
CC=golang-dev
https://golang.org/cl/4446058
 2011-04-22 15:22:11 -04:00
Dmitriy Vyukov 29d78f1243 runtime: fix GOMAXPROCS vs garbage collection bug 
Fixes #1715.

R=golang-dev, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4434053
 2011-04-21 12:09:25 -04:00