[PATCH] docs: accounting/psi: drop stale 500ms window minimum from trigger docs

[PATCH] docs: accounting/psi: drop stale 500ms window minimum from trigger docs

[Tao Cui]

From: Tao Cui <cuitao@kylinos.cn>

psi.rst says trigger windows range "from 500ms to 10s" with a 50ms min
polling interval. That minimum was removed in commit 519fabc7aaba ("psi:
remove 500ms min window size limitation for triggers"): the polling-rate
protection moved to gating trigger creation behind CAP_SYS_RESOURCE,
which also stopped capping psi event latency.

Update the wording accordingly: windows up to 10s with no enforced
minimum; trigger creation requires CAP_SYS_RESOURCE on cgroup pressure
files, while unprivileged users on /proc/pressure/ are limited to 2s
multiples.

Signed-off-by: Tao Cui <cuitao@kylinos.cn>
---
 Documentation/accounting/psi.rst | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst
index d455db3e5808..aae57fb5f15c 100644
--- a/Documentation/accounting/psi.rst
+++ b/Documentation/accounting/psi.rst
@@ -99,15 +99,14 @@ psi metric and deactivates upon exit from the stall state. While system is
 in the stall state psi signal growth is monitored at a rate of 10 times per
 tracking window.
 
-The kernel accepts window sizes ranging from 500ms to 10s, therefore min
-monitoring update interval is 50ms and max is 1s. Min limit is set to
-prevent overly frequent polling. Max limit is chosen as a high enough number
-after which monitors are most likely not needed and psi averages can be used
-instead.
-
-Unprivileged users can also create monitors, with the only limitation that the
-window size must be a multiple of 2s, in order to prevent excessive resource
-usage.
+The kernel accepts window sizes up to 10s. The 10s maximum is chosen as a
+high enough number after which monitors are most likely not needed and psi
+averages can be used instead.
+
+To prevent excessive resource usage, trigger creation is restricted to
+privileged users (CAP_SYS_RESOURCE) on cgroup pressure files; on the
+system-wide /proc/pressure/ files unprivileged users can create monitors
+as well, limited to window sizes that are a multiple of 2s.
 
 When activated, psi monitor stays active for at least the duration of one
 tracking window to avoid repeated activations/deactivations when system is
-- 
2.43.0

Re: [PATCH] docs: accounting/psi: drop stale 500ms window minimum from trigger docs

[Suren Baghdasaryan]

On Thu, Jul 23, 2026 at 5:51 AM Tao Cui <cui.tao@linux.dev> wrote:
>
> From: Tao Cui <cuitao@kylinos.cn>
>
> psi.rst says trigger windows range "from 500ms to 10s" with a 50ms min
> polling interval. That minimum was removed in commit 519fabc7aaba ("psi:
> remove 500ms min window size limitation for triggers"): the polling-rate
> protection moved to gating trigger creation behind CAP_SYS_RESOURCE,
> which also stopped capping psi event latency.
>
> Update the wording accordingly: windows up to 10s with no enforced
> minimum; trigger creation requires CAP_SYS_RESOURCE on cgroup pressure
> files, while unprivileged users on /proc/pressure/ are limited to 2s
> multiples.
>
> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
> ---
>  Documentation/accounting/psi.rst | 17 ++++++++---------
>  1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst
> index d455db3e5808..aae57fb5f15c 100644
> --- a/Documentation/accounting/psi.rst
> +++ b/Documentation/accounting/psi.rst
> @@ -99,15 +99,14 @@ psi metric and deactivates upon exit from the stall state. While system is
>  in the stall state psi signal growth is monitored at a rate of 10 times per
>  tracking window.
>
> -The kernel accepts window sizes ranging from 500ms to 10s, therefore min
> -monitoring update interval is 50ms and max is 1s. Min limit is set to
> -prevent overly frequent polling. Max limit is chosen as a high enough number
> -after which monitors are most likely not needed and psi averages can be used
> -instead.
> -
> -Unprivileged users can also create monitors, with the only limitation that the
> -window size must be a multiple of 2s, in order to prevent excessive resource
> -usage.
> +The kernel accepts window sizes up to 10s. The 10s maximum is chosen as a
> +high enough number after which monitors are most likely not needed and psi
> +averages can be used instead.
> +
> +To prevent excessive resource usage, trigger creation is restricted to
> +privileged users (CAP_SYS_RESOURCE) on cgroup pressure files; on the
> +system-wide /proc/pressure/ files unprivileged users can create monitors
> +as well, limited to window sizes that are a multiple of 2s.

Hmm. From this wording it sounds like we have different trigger
creation rules for system-wide vs cgroup pressure files, which I think
is not true. AFAICT, for both types, we restrict unprivileged users to
creating triggers with 2s window size multiples.

>
>  When activated, psi monitor stays active for at least the duration of one
>  tracking window to avoid repeated activations/deactivations when system is
> --
> 2.43.0
>

Re: [PATCH] docs: accounting/psi: drop stale 500ms window minimum from trigger docs

[Tao Cui]

在 2026/7/27 14:08, Suren Baghdasaryan 写道:
> On Thu, Jul 23, 2026 at 5:51 AM Tao Cui <cui.tao@linux.dev> wrote:
>>
>> From: Tao Cui <cuitao@kylinos.cn>
>>
>> psi.rst says trigger windows range "from 500ms to 10s" with a 50ms min
>> polling interval. That minimum was removed in commit 519fabc7aaba ("psi:
>> remove 500ms min window size limitation for triggers"): the polling-rate
>> protection moved to gating trigger creation behind CAP_SYS_RESOURCE,
>> which also stopped capping psi event latency.
>>
>> Update the wording accordingly: windows up to 10s with no enforced
>> minimum; trigger creation requires CAP_SYS_RESOURCE on cgroup pressure
>> files, while unprivileged users on /proc/pressure/ are limited to 2s
>> multiples.
>>
>> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
>> ---
>>  Documentation/accounting/psi.rst | 17 ++++++++---------
>>  1 file changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst
>> index d455db3e5808..aae57fb5f15c 100644
>> --- a/Documentation/accounting/psi.rst
>> +++ b/Documentation/accounting/psi.rst
>> @@ -99,15 +99,14 @@ psi metric and deactivates upon exit from the stall state. While system is
>>  in the stall state psi signal growth is monitored at a rate of 10 times per
>>  tracking window.
>>
>> -The kernel accepts window sizes ranging from 500ms to 10s, therefore min
>> -monitoring update interval is 50ms and max is 1s. Min limit is set to
>> -prevent overly frequent polling. Max limit is chosen as a high enough number
>> -after which monitors are most likely not needed and psi averages can be used
>> -instead.
>> -
>> -Unprivileged users can also create monitors, with the only limitation that the
>> -window size must be a multiple of 2s, in order to prevent excessive resource
>> -usage.
>> +The kernel accepts window sizes up to 10s. The 10s maximum is chosen as a
>> +high enough number after which monitors are most likely not needed and psi
>> +averages can be used instead.
>> +
>> +To prevent excessive resource usage, trigger creation is restricted to
>> +privileged users (CAP_SYS_RESOURCE) on cgroup pressure files; on the
>> +system-wide /proc/pressure/ files unprivileged users can create monitors
>> +as well, limited to window sizes that are a multiple of 2s.
> 
> Hmm. From this wording it sounds like we have different trigger
> creation rules for system-wide vs cgroup pressure files, which I think
> is not true. AFAICT, for both types, we restrict unprivileged users to
> creating triggers with 2s window size multiples.
> 

Sorry, I missed part of the history here. 8b39d20eceed reverted the
cgroup-specific gating that 519fabc7aaba added, so the 2s-multiple rule
applies the same way to both system-wide and cgroup files. I'll send a
v2 that keeps the window-range fix but restores the original unified
wording.

Thanks,
Tao

>>
>>  When activated, psi monitor stays active for at least the duration of one
>>  tracking window to avoid repeated activations/deactivations when system is
>> --
>> 2.43.0
>>