Address PR feedback

Author: pablogsal

.github/CODEOWNERS

@@ -703,7 +703,7 @@ peps/pep-0826.rst  @savannahostrowski
 peps/pep-0827.rst  @1st1
 peps/pep-0828.rst  @ZeroIntensity
 peps/pep-0829.rst  @warsaw
-peps/pep-0830.rst  @pablogsal @Fidget-Spinner @savannahostrowski
+peps/pep-0831.rst  @pablogsal @Fidget-Spinner @savannahostrowski
 # ...
 peps/pep-2026.rst  @hugovk
 # ...

peps/pep-0830.rst peps/pep-0831.rstpeps/pep-0830.rst renamed to peps/pep-0831.rst

@@ -1,4 +1,4 @@
-PEP: 830
+PEP: 831
 Title: Frame Pointers Everywhere: Enabling System-Level Observability for Python
 Author: Pablo Galindo Salgado <pablogsal@python.org>,
         Ken Jin <kenjin@python.org>,
@@ -67,7 +67,7 @@ default experience for Python.
 
 The performance wins that profiling enables far outweigh the modest overhead of
 frame pointers.  As Brendan Gregg notes: "I've seen frame pointers help find
-performance wins ranging from 5% to 500%" [#gregg2024]_.  A 1-2% overhead that
+performance wins ranging from 5% to 500%" [#gregg2024]_.  A 0.5-2% overhead that
 unlocks the ability to find 5-500% improvements is a favourable trade.
 
 What Are Frame Pointers?
@@ -109,7 +109,7 @@ At optimisation levels ``-O1`` and above, GCC and Clang omit frame pointers by
 default [#gcc_fomit]_.  This frees the ``%rbp`` register for general use,
 giving the optimiser one more register to work with. On x86-64 this is a gain
 of one register out of 16 (about 7%).  The performance benefit is small
-(typically 1-2%) but it was considered worthwhile when the convention was
+(typically 0.5-2%) but it was considered worthwhile when the convention was
 established for 32-bit x86, where the gain was one register out of 6 (~20%).
 
 Without frame pointers, the linked list does not exist.  Tools that need to
@@ -611,7 +611,7 @@ system calls.
 A common misconception in the community is that frame pointers carry large
 overhead "because there was a single Python case that had a +10% slowdown."
 [#hn-fp]_  That single case is the eval loop benchmark; the geometric mean
-across real workloads is 1-2%.
+across real workloads is 0.5-2%.
 
 Detailed Performance Analysis of CPython with Frame Pointers
 ------------------------------------------------------------
@@ -764,7 +764,7 @@ This distinguishes frame pointers from other flags placed in ``CFLAGS_NODIST``:
 those flags (such as ``-Werror`` or internal warning suppressions) are
 correctness or policy controls that are meaningful per-compilation-unit.  Frame
 pointers are an ecosystem-wide property that is only effective when all
-participants cooperate. The 1-2% overhead measured on CPython is driven by its
+participants cooperate. The 0.5-2% overhead measured on CPython is driven by its
 high density of small C helper function calls; typical C extension code does
 not exhibit the same call density and sees negligible overhead.
 
@@ -861,7 +861,7 @@ are compiled separately and unaffected by Python's ``CFLAGS``.  Extensions with
 hot scalar C loops (e.g., Cython-generated code) may see measurable but modest
 overhead.
 
-For context, 1-2% geometric mean is comparable to overhead routinely accepted
+For context, 0.5-2% geometric mean is comparable to overhead routinely accepted
 for build-time defaults such as ``-fstack-protector-strong`` (security) and the
 ASLR-compatible ``-fPIC`` flag for shared libraries.  In return, the entire
 Python ecosystem gains the ability to produce complete flame graphs, accurate
@@ -1074,11 +1074,11 @@ The first graph is the overall effect on pyperformance seen on each system.
 Apart from the Ubuntu AWS Graviton System, all system configurations have below 2%
 geometric mean and median slowdown:
 
-.. image:: pep-0830_perf_over_baseline.svg
+.. image:: pep-0831_perf_over_baseline.svg
 
 For individual benchmark results, see the following:
 
-.. image:: pep-0830_perf_over_baseline_indiv.svg
+.. image:: pep-0831_perf_over_baseline_indiv.svg
 
 
 Copyright