_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>
diff --git a/_content/doc/gc-guide.html b/_content/doc/gc-guide.html
index 3addb0b..cc081c6 100644
--- a/_content/doc/gc-guide.html
+++ b/_content/doc/gc-guide.html
@@ -1192,7 +1192,7 @@
 		<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 @@
 			</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>