design/44167-gc-pacer-redesign: clarify the role of the PI controller
For #44167.
Change-Id: Ifb77d37798842b7b31addebd8512a9272bd1a665
Reviewed-on: https://go-review.googlesource.com/c/proposal/+/442784
Reviewed-by: Michael Knyszek <mknyszek@google.com>
diff --git a/design/44167-gc-pacer-redesign.md b/design/44167-gc-pacer-redesign.md
index 62909bf..7020d13 100644
--- a/design/44167-gc-pacer-redesign.md
+++ b/design/44167-gc-pacer-redesign.md
@@ -23,8 +23,7 @@
1. Including all non-heap sources of GC work (stacks, globals) in pacing
decisions.
-1. Reframing the pacing problem as a search problem, solved by a
- proportional-integral controller,
+1. Reframing the pacing problem as a search problem,
1. Extending the hard heap goal to the worst-case heap goal of the next GC,
(1) will resolve long-standing issues with small heap sizes, allowing the Go
@@ -356,6 +355,10 @@
amount of noise, so smoothing over transient changes to this value is desirable.
To do so, I propose using this measurement as the set-point for a
proportional-integral (PI) controller.
+This means that the PI controller is always chasing whatever value was measured
+for each GC cycle.
+In a steady-state with only small changes, this means the PI controller acts as
+a smoothing function.
The advantage of a PI controller over a proportional controller is that it
guarantees that steady-state error will be driven to zero.
@@ -372,12 +375,13 @@
of research and use behind them, and this design lets us take advantage of that
and tune the pacer further if need be.
-Why a PI controller and not a PID controller? The PI controllers are simpler to
-reason about, and the derivative term in a PID controller tends to be sensitive
-to high-frequency noise.
-The advantage of the derivative term is a shorter rise time, but simulations
-show that the rise time is roughly 1 GC cycle, so I don't think there's much
-reason to include it just yet.
+Why a PI controller and not a PID controller?
+Firstly, PI controllers are simpler to reason about.
+Secondly, the derivative term in a PID controller tends to be sensitive to
+high-frequency noise, and the entire point here is to smooth over noise.
+Furthermore, the advantage of the derivative term is a shorter rise time, but
+simulations show that the rise time is roughly 1 GC cycle, so I don't think
+there's much reason to include it.
Adding the derivative term though is trivial once the rest of the design is in
place, so the door is always open.
diff --git a/design/44167/gc-pacer-redesign.src.md b/design/44167/gc-pacer-redesign.src.md
index 2662215..7801602 100644
--- a/design/44167/gc-pacer-redesign.src.md
+++ b/design/44167/gc-pacer-redesign.src.md
@@ -23,8 +23,7 @@
1. Including all non-heap sources of GC work (stacks, globals) in pacing
decisions.
-1. Reframing the pacing problem as a search problem, solved by a
- proportional-integral controller,
+1. Reframing the pacing problem as a search problem,
1. Extending the hard heap goal to the worst-case heap goal of the next GC,
(1) will resolve long-standing issues with small heap sizes, allowing the Go
@@ -359,6 +358,10 @@
amount of noise, so smoothing over transient changes to this value is desirable.
To do so, I propose using this measurement as the set-point for a
proportional-integral (PI) controller.
+This means that the PI controller is always chasing whatever value was measured
+for each GC cycle.
+In a steady-state with only small changes, this means the PI controller acts as
+a smoothing function.
The advantage of a PI controller over a proportional controller is that it
guarantees that steady-state error will be driven to zero.
@@ -375,12 +378,13 @@
of research and use behind them, and this design lets us take advantage of that
and tune the pacer further if need be.
-Why a PI controller and not a PID controller? The PI controllers are simpler to
-reason about, and the derivative term in a PID controller tends to be sensitive
-to high-frequency noise.
-The advantage of the derivative term is a shorter rise time, but simulations
-show that the rise time is roughly 1 GC cycle, so I don't think there's much
-reason to include it just yet.
+Why a PI controller and not a PID controller?
+Firstly, PI controllers are simpler to reason about.
+Secondly, the derivative term in a PID controller tends to be sensitive to
+high-frequency noise, and the entire point here is to smooth over noise.
+Furthermore, the advantage of the derivative term is a shorter rise time, but
+simulations show that the rise time is roughly 1 GC cycle, so I don't think
+there's much reason to include it.
Adding the derivative term though is trivial once the rest of the design is in
place, so the door is always open.
