_content/doc/gc-guide: explain mark worker types

Within background mark workers we already have "dedicated",
"fractional", and "idle" workers. Those aren't currently discussed in
this doc, but the idle worker note would be more clear if it did, so
adjust.

Change-Id: I44446cfd157fdae6be29c961052dbdabb1394bcf
Reviewed-on: https://go-review.googlesource.com/c/website/+/531707
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This commit is contained in:
Michael Pratt 2023-10-02 15:33:28 -04:00 коммит произвёл Gopher Robot
Родитель 8a1e138e64
Коммит 438b262fe1
1 изменённых файлов: 14 добавлений и 5 удалений

Просмотреть файл

@ -1192,7 +1192,7 @@ them in in order to understand GC impact and behavior.
<li>
<p>
<b><code>runtime.gcBgMarkWorker</code></b>: Entrypoint to the
dedicated mark worker goroutines.
background mark worker goroutines.
Time spent here scales with GC frequency and the complexity and
size of the object graph.
It represents a baseline for how much time the application spends
@ -1200,10 +1200,19 @@ them in in order to understand GC impact and behavior.
</p>
<p>
<i>
Note: In a largely idle Go application, the Go GC is going to
use up additional (idle) CPU resources to get its job done faster.
As a result, this symbol may represent a large fraction of samples,
that it believes are free.
Note: Within these goroutines, you will find calls to
<code>runtime.gcDrainMarkWorkerDedicated</code>,
<code>runtime.gcDrainMarkWorkerFractional</code>, and
<code>runtime.gcDrainMarkWorkerIdle</code>,
which indicate worker type.
In a largely idle Go application, the Go GC is going to use up
additional (idle) CPU resources to get its job done faster, which
is indicated with the <code>runtime.gcDrainMarkWorkerIdle</code>
symbol.
As a result, time here may represent a large fraction of CPU
samples, which the Go GC believes are free.
If the application becomes more active, CPU time in idle workers
will drop.
One common reason this can happen is if an application runs entirely
in one goroutine but </i><code>GOMAXPROCS</code><i> is &gt;1.
</i>