Skip to content

runtime: TestStackBarrierProfiling failing on mipsle #17936

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bradfitz opened this issue Nov 16, 2016 · 7 comments
Closed

runtime: TestStackBarrierProfiling failing on mipsle #17936

bradfitz opened this issue Nov 16, 2016 · 7 comments
Milestone

Comments

@bradfitz
Copy link
Contributor

linux-mipsle at 1b66b38
https://build.golang.org/log/59970800b3d64dc2d3d4231a7de764086a67ac15

--- FAIL: TestStackBarrierProfiling (6.99s)
	pprof_test.go:374: subprocess failed with exit status 1:
		--- FAIL: TestStackBarrierProfiling (6.92s)
			pprof_test.go:193: total 2 CPU profile samples collected
			pprof_test.go:205: too few samples; got 2, want at least 5, ideally 20
			pprof_test.go:150: retrying with 400ms duration
			pprof_test.go:193: total 8 CPU profile samples collected
			pprof_test.go:205: too few samples; got 8, want at least 10, ideally 40
			pprof_test.go:150: retrying with 800ms duration
			pprof_test.go:193: total 15 CPU profile samples collected
			pprof_test.go:205: too few samples; got 15, want at least 20, ideally 80
			pprof_test.go:150: retrying with 1.6s duration
			pprof_test.go:193: total 31 CPU profile samples collected
			pprof_test.go:205: too few samples; got 31, want at least 40, ideally 160
			pprof_test.go:150: retrying with 3.2s duration
			pprof_test.go:193: total 33 CPU profile samples collected
			pprof_test.go:205: too few samples; got 33, want at least 80, ideally 320
		FAIL
FAIL
FAIL	runtime/pprof	11.166s

/cc @vstefanovic @cherrymui

@bradfitz bradfitz added this to the Go1.8 milestone Nov 16, 2016
@cherrymui
Copy link
Member

Is it due to issue #13405, in particular, #13405 (comment) ?

$ gomote run user-cherryyz-linux-mipsle-0 /bin/zcat /proc/config.gz | grep 'CONFIG_HZ\|HIGH_RES'
# CONFIG_HZ_24 is not set
# CONFIG_HZ_48 is not set
CONFIG_HZ_100=y
# CONFIG_HZ_128 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_256 is not set
# CONFIG_HZ_1000 is not set
# CONFIG_HZ_1024 is not set
CONFIG_HZ=100
CONFIG_HZ_PERIODIC=y
# CONFIG_HIGH_RES_TIMERS is not set

/cc @aclements

@bradfitz
Copy link
Contributor Author

@cherrymui, good find. Seems likely.

Should we make that test do the /bin/zcat /proc/config.gz and skip if it doesn't find CONFIG_HIGH_RES_TIMERS set?

@gopherbot
Copy link
Contributor

CL https://golang.org/cl/33306 mentions this issue.

@bradfitz
Copy link
Contributor Author

/cc @vstefanovic

@aclements
Copy link
Member

Since stack barriers aren't even on by default now, I'm sure this is the timing issue. (I'll be removing this test in Go 1.9 when I remove support for stack barriers.)

I'm not positive, but I think CONFIG_HZ_100 would actually be fine if CONFIG_HIGH_RES_TIMERS were set.

@cherrymui
Copy link
Member

@bradfitz, just found http://elinux.org/High_Resolution_Timers#How_to_detect_if_your_timer_system_supports_high_resolution
maybe grep resolution /proc/timer_list is a better way to find out timer resolution (given that kernel config may not always available)?

@bradfitz
Copy link
Contributor Author

@cherrymui, feel free to improve it. I don't know exactly how to parse /proc/timer_list. I'm just trying to get build.golang.org to not be so red.

@golang golang locked and limited conversation to collaborators Nov 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants