Skip to content
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

runtime: TestStackBarrierProfiling failing on mipsle #17936

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

Comments

Projects
None yet
4 participants
@bradfitz
Copy link
Member

commented Nov 16, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Nov 16, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Nov 16, 2016

@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

This comment has been minimized.

Copy link

commented Nov 16, 2016

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

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Nov 16, 2016

@aclements

This comment has been minimized.

Copy link
Member

commented Nov 16, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Nov 16, 2016

@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)?

@gopherbot gopherbot closed this in cd66c38 Nov 16, 2016

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Nov 16, 2016

@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.
You can’t perform that action at this time.