From da0e37fa8d284e92972877c4be3d031ecf1c8334 Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Wed, 22 Apr 2015 16:38:04 -0400 Subject: [PATCH] runtime: benchmark for ping-pong in the presence of a CPU hog This benchmark demonstrates a current problem with the scheduler where a set of frequently communicating goroutines get very little CPU time in the presence of another goroutine that hogs that CPU, even if one of those communicating goroutines is always runnable. Currently it takes about 0.5 milliseconds to switch between ping-ponging goroutines in the presence of a CPU hog: BenchmarkPingPongHog 2000 684287 ns/op Change-Id: I278848c84f778de32344921ae8a4a8056e4898b0 Reviewed-on: https://go-review.googlesource.com/9288 Reviewed-by: Rick Hudson Reviewed-by: Russ Cox --- src/runtime/proc_test.go | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/src/runtime/proc_test.go b/src/runtime/proc_test.go index 88cd48486a..af90215238 100644 --- a/src/runtime/proc_test.go +++ b/src/runtime/proc_test.go @@ -292,6 +292,43 @@ func main() { } ` +func BenchmarkPingPongHog(b *testing.B) { + defer runtime.GOMAXPROCS(runtime.GOMAXPROCS(1)) + + // Create a CPU hog + stop, done := make(chan bool), make(chan bool) + go func() { + for { + select { + case <-stop: + done <- true + return + default: + } + } + }() + + // Ping-pong b.N times + ping, pong := make(chan bool), make(chan bool) + go func() { + for j := 0; j < b.N; j++ { + pong <- <-ping + } + close(stop) + }() + go func() { + for i := 0; i < b.N; i++ { + ping <- <-pong + } + }() + b.ResetTimer() + ping <- true // Start ping-pong + <-stop + b.StopTimer() + <-ping // Let last ponger exit + <-done // Make sure hog exits +} + func stackGrowthRecursive(i int) { var pad [128]uint64 if i != 0 && pad[0] == 0 { -- 2.50.0