runtime/pprof: TestStackBarrierProfiling too short on freebsd too

[bradfitz]

Should freebsd also be skipped? (part of #13841)

http://build.golang.org/log/a50792aa07a14b6644148e160b9858ff07a5e12f

--- FAIL: TestStackBarrierProfiling (0.51s)
    pprof_test.go:363: subprocess failed with exit status 1:
        --- FAIL: TestStackBarrierProfiling (0.49s)
            pprof_test.go:97: profile too short: [0x0 0x3 0x0 0x2710 0x0 0x0 0x1 0x0]
        FAIL
FAIL
FAIL    runtime/pprof   2.190s

[aclements]

FreeBSD has been failing a lot on the dashboard. I thought it had okay timer support, but I'll dig in to it.

[aclements]

FreeBSD is even worse in some ways. Like other Unixes it can only fire SIGPROF for the process running as of the system tick, but it also only accounts for elapsed itimer time as of the system tick. That is, if a whole bunch of processes run during a quantum, each yielding to the next; the one running at the end of the quantum will be attributed the whole time slice and none of the other processes will record any time elapsed. (This is all based on FreeBSD 10.)

usleep doesn't seem as obviously broken as on some platforms (it doesn't seem to unconditionally give up the whole time slice), but it's definitely not very precise. I'm still figuring out what usleep does.

[aclements]

usleep also gives up the rest of the time slice on FreeBSD, and maybe two time slices. A usleep(100) loop sleeps for a mean of 2ms with little variance. The test doesn't fail as often on FreeBSD because the default time slice is only 1ms (according to /sbin/sysctl kern.hz), which is less than on the other systems. However, it has the same underlying problem.

[gopherbot]

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