Causalprof #1
Open
Causalprof #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DanielMorsing
force-pushed
the
causalprof
branch
from
0d42c5e to
4124e6a
Compare
DanielMorsing
pushed a commit
that referenced
this pull request
Jun 17, 2018
Every time I see an error that begins `missing argument for Fprintf("%s")`
my mental type-checker goes off, since obviously "%s" is not a valid first
argument to Fprintf. Writing Printf("%s") to report an error in Printf("hello %s")
is almost as confusing.
This CL rewords the errors reported by vet's printf check to be more
consistent with each other, avoid placing context like "in printf call"
in the middle of the message, and to avoid the imprecisions above by
not quoting the format string at all.
Before:
bad.go:9: no formatting directive in Printf call
bad.go:10: missing argument for Printf("%s"): format reads arg 1, have only 0 args
bad.go:11: wrong number of args for format in Printf call: 1 needed but 2 args
bad.go:12: bad syntax for printf argument index: [1]
bad.go:13: index value [0] for Printf("%[0]s"); indexes start at 1
bad.go:14: missing argument for Printf("%[2]s"): format reads arg 2, have only 1 args
bad.go:15: bad syntax for printf argument index: [abc]
bad.go:16: unrecognized printf verb 'z'
bad.go:17: arg "hello" for * in printf format not of type int
bad.go:18: arg fmt.Sprint in printf call is a function value, not a function call
bad.go:19: arg fmt.Sprint in Print call is a function value, not a function call
bad.go:20: arg "world" for printf verb %d of wrong type: string
bad.go:21: missing argument for Printf("%q"): format reads arg 2, have only 1 args
bad.go:22: first argument to Print is os.Stderr
bad.go:23: Println call ends with newline
bad.go:32: arg r in Sprint call causes recursive call to String method
bad.go:34: arg r for printf causes recursive call to String method
After:
bad.go:9: Printf call has arguments but no formatting directives
bad.go:10: Printf format %s reads arg #1, but have only 0 args
bad.go:11: Printf call needs 1 args but has 2 args
bad.go:12: Printf format %[1 is missing closing ]
bad.go:13: Printf format has invalid argument index [0]
bad.go:14: Printf format has invalid argument index [2]
bad.go:15: Printf format has invalid argument index [abc]
bad.go:16: Printf format %.234z has unknown verb z
bad.go:17: Printf format %.*s uses non-int "hello" as argument of *
bad.go:18: Printf format %s arg fmt.Sprint is a func value, not called
bad.go:19: Print arg fmt.Sprint is a func value, not called
bad.go:20: Printf format %d has arg "world" of wrong type string
bad.go:21: Printf format %q reads arg golang#2, but have only 1 args
bad.go:22: Print does not take io.Writer but has first arg os.Stderr
bad.go:23: Println args end with redundant newline
bad.go:32: Sprint arg r causes recursive call to String method
bad.go:34: Sprintf format %s with arg r causes recursive String method call
Change-Id: I5719f0fb9f2cd84df8ad4c7754ab9b79c691b060
Reviewed-on: https://go-review.googlesource.com/74352
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
DanielMorsing
force-pushed
the
causalprof
branch
from
4124e6a to
f91254c
Compare
Change-Id: Ic7997d1f747152afec78e8e439770166029f34ec GitHub-Last-Rev: 6a07f25 GitHub-Pull-Request: golang#36491 Reviewed-on: https://go-review.googlesource.com/c/go/+/214298 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
This imports CL 213880. Fixes golang#35511 Change-Id: I55d18713bdac8fa556ba5a2aced922f80d1ac970 Reviewed-on: https://go-review.googlesource.com/c/go/+/214078 Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When adjustTimers sees a timerModifiedEarlier or timerModifiedLater, it removes it from the heap, leaving a new timer at that position in the heap. We were accidentally skipping that new timer in our loop. In some unlikely cases this could cause adjustTimers to look at more timers than necessary. Change-Id: Ic71e54c175ab7d86a7fa46f1497aca71ed1c43cc Reviewed-on: https://go-review.googlesource.com/c/go/+/214338 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
This pulls in two new commits: a fix for a test broken on plan9 and a correction to a comment. Change-Id: I31cf046a5073872714c758894732b2fcc800ab6b Reviewed-on: https://go-review.googlesource.com/c/go/+/214289 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
Make file names consistent, using only forward slashes in the path. Fixes golang#36495 Change-Id: I337119d6dff233ab9d4bfe757147ec25961ae021 Reviewed-on: https://go-review.googlesource.com/c/go/+/214286 Run-TryBot: Jeremy Faller <jeremy@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
We had a few test cases to make sure checkptr didn't have certain false positives, but none to test for any true positives. This CL fixes that. Updates golang#22218. Change-Id: I24c02e469a4af43b1748829a9df325ce510f7cc4 Reviewed-on: https://go-review.googlesource.com/c/go/+/214238 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Updates golang#36489 Change-Id: I1ca215ba0a64a31d662134385b8be46bb4ba4434 Reviewed-on: https://go-review.googlesource.com/c/go/+/214282 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Whenever more than 1/4 of the timers on a P's heap are deleted, remove them from the heap. Change-Id: Iff63ed3d04e6f33ffc5c834f77f645c52c007e52 Reviewed-on: https://go-review.googlesource.com/c/go/+/214299 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
The comment contained a link that had a file name and ID that no longer existed, so change to the URL of the corresponding part of the latest page. Change-Id: I74e0885aabf470facc39b84035f7a83fef9c6a8e GitHub-Last-Rev: 5681c84 GitHub-Pull-Request: golang#36514 Reviewed-on: https://go-review.googlesource.com/c/go/+/214181 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change the type printer to take a map of types that we're currently printing. When we happen upon a type that we're already in the middle of printing, print a reference to it instead. A reference to another type is built using the offset of the first byte of that type's string representation in the result. To facilitate that computation (and it's probably more efficient, regardless), we print the type to a buffer as we go, and build the string at the end. It would be nice to use string.Builder instead of bytes.Buffer, but string.Builder wasn't around in Go 1.4, and we'd like to bootstrap from that version. Fixes golang#29312 Change-Id: I49d788c1fa20f770df7b2bae3b9979d990d54803 Reviewed-on: https://go-review.googlesource.com/c/go/+/214239 Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes golang#36375 Change-Id: I407a1db23868880b83e73bc136d274659483fb69 Reviewed-on: https://go-review.googlesource.com/c/go/+/214437 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes golang#36526. Change-Id: Ic51a287579f139422cc1a7b2fb82d6732114b031 Reviewed-on: https://go-review.googlesource.com/c/go/+/214597 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since Durations only span 290 years, they are not good for manipulating very remote times. I bounced off this problem recently while doing some astronomical calculations and it took me a while to realize I could get a 64-bit seconds value from time.Time.Unix and subtract two of them to evaluate the interval. I thought it worth adding a sentence to make this clear. It didn't occur to me for quite a while that "Unix time" spans a huge range in the Go library. Change-Id: I76c75dc951dfd6bcf86e8b0be3cfec518a3ecdee Reviewed-on: https://go-review.googlesource.com/c/go/+/213977 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
This reverts CL 214437. Does not fix the issue, and the test was wrong so it did not detect that it did not fix the issue. Updates golang#36375 Change-Id: I6a4112035a1e90f4fdafed6fdf4ec9dfc718b571 Reviewed-on: https://go-review.googlesource.com/c/go/+/214601 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Even though I contributed to golang/go[^1], the rule[^2] did not reflect my name in CONTRIBUTORS, so I added it. [^1]: https://go-review.googlesource.com/c/go/+/164199 [^2]: https://github.com/golang/build/blob/e21a90b/cmd/updatecontrib/updatecontrib.go#L118 Change-Id: I5d6b5684d61ea5da679519a9e703d977470de175 Reviewed-on: https://go-review.googlesource.com/c/go/+/214617 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, the scavenger is paced according to how long it takes to scavenge one runtime page's worth of memory. However, this pacing doesn't take into account the additional cost of actually using a scavenged page. This operation, "sysUsed," is a counterpart to the scavenging operation "sysUnused." On most systems this operation is a no-op, but on some systems like Darwin and Windows we actually make a syscall. Even on systems where it's a no-op, the cost is implicit: a more expensive page fault when re-using the page. On Darwin in particular the cost of "sysUnused" is fairly close to the cost of "sysUsed", which skews the pacing to be too fast. A lot of soon-to-be-allocated memory ends up scavenged, resulting in many more expensive "sysUsed" operations, ultimately slowing down the application. The way to fix this problem is to include the future cost of "sysUsed" on a page in the scavenging cost. However, measuring the "sysUsed" cost directly (like we do with "sysUnused") on most systems is infeasible because we would have to measure the cost of the first access. Instead, this change applies a multiplicative constant to the measured scavenging time which is based on a per-system ratio of "sysUnused" to "sysUsed" costs in the worst case (on systems where it's a no-op, we measure the cost of the first access). This ultimately slows down the scavenger to a more reasonable pace, limiting its impact on performance but still retaining the memory footprint improvements from the previous release. Fixes golang#36507. Change-Id: I050659cd8cdfa5a32f5cc0b56622716ea0fa5407 Reviewed-on: https://go-review.googlesource.com/c/go/+/214517 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
This reduces lock contention when only a few P's are running and checking for whether they need to run timers on the sleeping P's. Without this change the running P's would get lock contention while looking at the sleeping P's timers. With this change a single atomic load suffices to determine whether there are any ready timers. Change-Id: Ie843782bd56df49867a01ecf19c47498ec827452 Reviewed-on: https://go-review.googlesource.com/c/go/+/214185 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com>
The HTML linter 'tidy' reports: go_spec.html:2556: Warning: unescaped & which should be written as & go_spec.html:3293: Warning: unescaped & or unknown entity "&s1" go_spec.html:3293: Warning: unescaped & or unknown entity "&a" go_spec.html:3294: Warning: unescaped & or unknown entity "&s2" go_spec.html:3294: Warning: unescaped & or unknown entity "&a" go_spec.html:2045: Warning: trimming empty <p> go_spec.html:4526: Warning: trimming empty <ul> go_spec.html:4533: Warning: trimming empty <ul> go_spec.html:4539: Warning: trimming empty <ul> This CL fixes all but the <ul> ones, which I think should be fixed but are defended by a comment. Change-Id: I0ca88f5e80755024801877ab1298025ecf8f10c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/214457 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Change-Id: I83f806e76ef4d268b187bd273d78ceb41b7e8fa5 GitHub-Last-Rev: ee82eaa GitHub-Pull-Request: golang#36194 Reviewed-on: https://go-review.googlesource.com/c/go/+/211799 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes golang#36520 Change-Id: I698ab235f82f7c81caa09318c954847cf3833153 GitHub-Last-Rev: 368a1dc GitHub-Pull-Request: golang#36559 Reviewed-on: https://go-review.googlesource.com/c/go/+/214821 Reviewed-by: Robert Griesemer <gri@golang.org>
Go 1.14 will drop support for macOS 10.10, see golang#23011 This reverts CL 155097 Updates golang#26475 Updates golang#29340 Change-Id: I64d0275141407313b73068436ee81d13eacc4c76 Reviewed-on: https://go-review.googlesource.com/c/go/+/214058 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Based on riscv-go port. Updates golang#27532 Change-Id: Id8ae7d851c393ec3702e4176c363accb0a42587f Reviewed-on: https://go-review.googlesource.com/c/go/+/204633 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I noticed this leak while writing CL 214977. Change-Id: I7566952b8e4bc58939d23435aea86576fc58ddca Reviewed-on: https://go-review.googlesource.com/c/go/+/214978 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 214239 improved type printing, but introduced performance regressions: 3-5% memory increase, 1-2% CPU time increase. There were two primary sources of the memory regression: * allocating a bytes.Buffer for every type to print * always printing to that buffer, even when we could return a constant string This change addresses both of those regressions. The sync.Pool allows buffer re-use. String interning prevents allocation for re-used strings. It addresses some, but not all, of the CPU time regression. Memory performance impact vs master: name old alloc/op new alloc/op delta Template 37.6MB ± 0% 36.3MB ± 0% -3.30% (p=0.008 n=5+5) Unicode 28.7MB ± 0% 28.3MB ± 0% -1.55% (p=0.008 n=5+5) GoTypes 127MB ± 0% 122MB ± 0% -4.38% (p=0.008 n=5+5) Compiler 584MB ± 0% 568MB ± 0% -2.72% (p=0.008 n=5+5) SSA 1.99GB ± 0% 1.95GB ± 0% -1.97% (p=0.008 n=5+5) Flate 23.5MB ± 0% 22.8MB ± 0% -2.84% (p=0.008 n=5+5) GoParser 29.2MB ± 0% 28.0MB ± 0% -4.17% (p=0.008 n=5+5) Reflect 81.9MB ± 0% 78.6MB ± 0% -4.09% (p=0.008 n=5+5) Tar 35.3MB ± 0% 34.1MB ± 0% -3.29% (p=0.008 n=5+5) XML 45.5MB ± 0% 44.3MB ± 0% -2.61% (p=0.008 n=5+5) [Geo mean] 82.4MB 79.9MB -3.09% name old allocs/op new allocs/op delta Template 394k ± 0% 363k ± 0% -7.73% (p=0.008 n=5+5) Unicode 340k ± 0% 329k ± 0% -3.25% (p=0.008 n=5+5) GoTypes 1.41M ± 0% 1.28M ± 0% -9.54% (p=0.008 n=5+5) Compiler 5.77M ± 0% 5.39M ± 0% -6.58% (p=0.008 n=5+5) SSA 19.1M ± 0% 18.1M ± 0% -5.13% (p=0.008 n=5+5) Flate 247k ± 0% 228k ± 0% -7.50% (p=0.008 n=5+5) GoParser 325k ± 0% 295k ± 0% -9.24% (p=0.008 n=5+5) Reflect 1.04M ± 0% 0.95M ± 0% -8.48% (p=0.008 n=5+5) Tar 365k ± 0% 336k ± 0% -7.93% (p=0.008 n=5+5) XML 449k ± 0% 417k ± 0% -7.10% (p=0.008 n=5+5) [Geo mean] 882k 818k -7.26% Memory performance going from 52c4488, which is the commit preceding CL 214239, to this change: name old alloc/op new alloc/op delta Template 36.5MB ± 0% 36.3MB ± 0% -0.37% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.3MB ± 0% -0.06% (p=0.008 n=5+5) GoTypes 123MB ± 0% 122MB ± 0% -0.64% (p=0.008 n=5+5) Compiler 571MB ± 0% 568MB ± 0% -0.51% (p=0.008 n=5+5) SSA 1.96GB ± 0% 1.95GB ± 0% -0.13% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% ~ (p=0.421 n=5+5) GoParser 28.1MB ± 0% 28.0MB ± 0% -0.37% (p=0.008 n=5+5) Reflect 78.8MB ± 0% 78.6MB ± 0% -0.32% (p=0.008 n=5+5) Tar 34.3MB ± 0% 34.1MB ± 0% -0.35% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.3MB ± 0% +0.05% (p=0.032 n=5+5) [Geo mean] 80.1MB 79.9MB -0.27% name old allocs/op new allocs/op delta Template 372k ± 0% 363k ± 0% -2.46% (p=0.008 n=5+5) Unicode 333k ± 0% 329k ± 0% -0.97% (p=0.008 n=5+5) GoTypes 1.33M ± 0% 1.28M ± 0% -3.71% (p=0.008 n=5+5) Compiler 5.53M ± 0% 5.39M ± 0% -2.50% (p=0.008 n=5+5) SSA 18.3M ± 0% 18.1M ± 0% -1.22% (p=0.008 n=5+5) Flate 234k ± 0% 228k ± 0% -2.44% (p=0.008 n=5+5) GoParser 305k ± 0% 295k ± 0% -3.23% (p=0.008 n=5+5) Reflect 980k ± 0% 949k ± 0% -3.12% (p=0.008 n=5+5) Tar 345k ± 0% 336k ± 0% -2.69% (p=0.008 n=5+5) XML 425k ± 0% 417k ± 0% -1.72% (p=0.008 n=5+5) [Geo mean] 838k 818k -2.41% Remaining CPU time regression, that is, the change from before CL 214239 to this change: name old time/op new time/op delta Template 208ms ± 2% 209ms ± 1% ~ (p=0.181 n=47+46) Unicode 82.9ms ± 2% 81.9ms ± 2% -1.25% (p=0.000 n=50+48) GoTypes 709ms ± 3% 714ms ± 3% +0.77% (p=0.003 n=48+49) Compiler 3.31s ± 2% 3.32s ± 2% ~ (p=0.271 n=48+48) SSA 10.8s ± 1% 10.9s ± 1% +0.61% (p=0.000 n=46+47) Flate 134ms ± 2% 134ms ± 1% +0.41% (p=0.002 n=48+46) GoParser 166ms ± 2% 167ms ± 2% +0.41% (p=0.010 n=46+48) Reflect 440ms ± 4% 444ms ± 4% +1.05% (p=0.002 n=50+49) Tar 183ms ± 2% 184ms ± 2% ~ (p=0.074 n=45+45) XML 247ms ± 2% 248ms ± 2% +0.67% (p=0.001 n=49+48) [Geo mean] 425ms 427ms +0.34% name old user-time/op new user-time/op delta Template 271ms ± 2% 271ms ± 2% ~ (p=0.654 n=48+48) Unicode 117ms ± 2% 116ms ± 3% ~ (p=0.458 n=47+45) GoTypes 952ms ± 3% 963ms ± 2% +1.11% (p=0.000 n=48+49) Compiler 4.50s ± 5% 4.49s ± 7% ~ (p=0.894 n=50+50) SSA 15.0s ± 2% 15.1s ± 2% +0.46% (p=0.015 n=50+49) Flate 166ms ± 2% 167ms ± 2% +0.40% (p=0.005 n=49+48) GoParser 202ms ± 2% 203ms ± 2% +0.60% (p=0.002 n=49+47) Reflect 583ms ± 3% 588ms ± 3% +0.82% (p=0.001 n=49+46) Tar 223ms ± 2% 224ms ± 2% +0.37% (p=0.046 n=48+46) XML 310ms ± 2% 311ms ± 2% +0.46% (p=0.009 n=50+49) [Geo mean] 554ms 556ms +0.36% Change-Id: I85951a6538373ef4309a2cc366cc1ebaf1f4582d Reviewed-on: https://go-review.googlesource.com/c/go/+/214818 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Fixes golang#36557 Change-Id: Ia8125f382d5e14e5612da811268a58971cc9ac08 Reviewed-on: https://go-review.googlesource.com/c/go/+/214917 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Austin Clements <austin@google.com>
Fixes golang#31651 Change-Id: Idbab0c4355fcc58520e210126795223435cf0078 Reviewed-on: https://go-review.googlesource.com/c/go/+/214822 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In CL 199821, we stopped setting the module directory for vendored packages when -mod=vendor is used. This broke -trimpath, since we replace the module directory with a string derived from the module path and version. A comment in CL 202977 makes it clear that the module directory should not be set. With this change, -trimpath falls back to replacing the package directory with the package path if the module directory is not set. We also fall back to replacing the package directory if the module version is not set to avoid adding a meaningless @ only for the main module. As a consequence of this change, file names in vendored packages will not have module versions, so file names will be a little different between -mod=mod and -mod=vendor. Fixes golang#36566 Change-Id: I0e9cd76d36a2028a49d0b6697ea9a9b3140d7ff3 Reviewed-on: https://go-review.googlesource.com/c/go/+/214945 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
Change-Id: Ic7b39f4422669ed284ccf0a1b8f8238d6511d134
This makes it so that sleeps executed are adjusted based on how sleeps were scheduled earlier. This makes all the results I have way less impressive, but good none-the-less Now that I have this info, try logging to see how badly the timer goroutine introduces lag Change-Id: I55feef92e75732c0c254df06b8869ac1be958c55
Change-Id: I118ebcd3830548f6fefcf9bfa7c3d528af871cd3
The original causal profiling paper uses several null experiments to guard against skew. Do the same here. Change-Id: I63e8edc6dd10ced234622e9a429c4781b23ed42a
Change-Id: I71bb940c98fd883a29ea52aaa8cebd3500838d9e
fixed deadlock when stopping profiling as well. Change-Id: I1b5bc663e524ae0ef2c3d5aa93f941a2ebf419ba
You could deadlock the system before if you managed to wait inside the start function. Also, clear out the cpu channel at all times. Change-Id: I713c907f3f534e90c5910cc385d53ed7565943aa
Change-Id: I2c7dcc0969123ac74e46a068e95f95e597b107e6
Change-Id: I13f26f6d1eab6dd450c81b15e5dfc834b09fda1b
Change-Id: I3e7cbe6d8b9a5d232c6d490932a04ab21e7e3319
Change-Id: I00feac56ac3d00ec0a937d70d655a6d6bee49178
Change-Id: Ic7522eb5f22cb0ed9088118b6fc8332fbff10cb0
Change-Id: Ia91a6833dbf29f4b43d602fbf05b79f816a49a18
Since dropg is only ever called on the g0, it simplifies the locking around Ps. It also catches the case where someone called runtime.Sched Change-Id: Ie06fdcc0c67f655ab586199269f522ece712b068
These were outside the scope of profiling since they interacted with the scheduler weirdly, but with the new M based sleep, these exceptions don't matter Change-Id: I62b9f7efacb9fc78e0a60bbec00631709d178708
Make sure we always do them on a system stack where Ps cannot move Change-Id: I2187c649172e837c2e99e752ffc002b47561ded2
Change-Id: I5c3d89c2911ba5771c120acbaaa69807d672005d
When a syscall is executed, the M might reclaim an idle P when returning. Effectively, that can mean that the G gets moved from one P to another. Hence, we need to mark the G as having been executed with the delay and pick up on the G if we come back from a syscall with an idle P. Change-Id: I86e8bb9e93589b7c580b6709e6941845af116949
This optimization was spurious, since a P being delayed means fewer opportunities to schedule.
Stop people reading stuff in the tealeaves
Change-Id: Ic7c8f0ec7346b712ced0f55e0d474f270edfd69f
Change-Id: Iaac6792dad5358159260c5ee0d7aa7693ff3fcf7
PRODUCTION READY!!!
Change-Id: I4d1f3abb1e5a65e917cde660e911bff3d25d74f4
This should make it more obvious when there's a split between CPU time spent and speed of program Change-Id: I00ec5559755799f4a883bdc047e621f8136a2b60
DanielMorsing
force-pushed
the
causalprof
branch
from
2fa51fc to
72204cf
Compare
|
Just wanted to pop in after reading your HTTP/2 blog post and say this is wicked cool. ❤️ I'd never heard of causal profiling before, and seeing it in practice as someone who looks at pprofs multiple times a day is awesome. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.