Feature Request: Expose PSI Information

[Columbus240]

With v4.20 the Linux kernel introduced a new metric for system usage, similar to the system load averages, called “Pressure Stall Information“ (PSI).
More infos about it on LWN.net or in Documentation/accounting/psi.txt of the Linux sources.
I’d like to show the PSI information using i3status.

It would be necessary to check whether the kernel has CONFIG_PSI enabled, which means checking whether the files in /proc/pressure exist. Then these files would have to be parsed and the information inserted into the format string given by the user in the i3status-config.

The documentation this feature in i3status should note, that the PSI is only available if the kernel has a version of at least 4.20 and was built with CONFIG_PSI enabled.

Currently there are rather many (15) numbers exposed by the PSI. (3 for cpu, 6 each for memory and io)
I don’t know how the config options for the PSI should look like so that they are easy to use. Something similar to the load average is probably a good idea.

[Airblader]

I'd be willing to consider this, it sounds useful. A proposal for what the config surface would look like and what kind of output would be achieved with it would be helpful :-)

[Columbus240]

I’ll present here a non exhaustive list of possible config surfaces. I used variations of the structure and of the variable names at the same time.
I haven’t thought much about how a good status line should look like, only about the config syntax.

A

pressure cpu {
    format = "%avg10 %avg60 %avg300 %total"
    max_threshold = 0.75
}
pressure memory some {
    format = "%10s %60s %300s %total"
    max_threshold = 0.75
}
pressure memory full {
    format = "%10sec %60sec %300sec %total"
    max_threshold = 0.5
}
pressure io some {
    format = "%10 %60 %300 %total"
    max_threshold = 0.9
}

Alternative: write pressure cpu some instead of pressure cpu.

The variable names used in the first block are directly taken from the syntax with which the kernel exposes the PSI. The advantage of using the second or the third variants of the variable names is a bigger consistency with the current config syntax for load which uses %1min, %5min and %15min.

B

pressure {
    format = "%cpu_some_10sec %cpu_some_60sec %cpu_some_300sec %cpu_some_total %memory_some_10s %memory_full_10s …"
}

How max_threshold would be implemented here is yet unclear to me. Would it "match" if any of the 10s values is bigger, or only if any of memory_full_10s, io_full_10s or cpu_some_10s are bigger? Are multiple threshold values necessary?

C

pressure cpu {
    format = "%some_avg10 %some_avg60 %some_avg300 %some_total"
    max_threshold = "0.75"
}
pressure memory {
    format = "%some_10sec %some_60sec %some_300sec %some_total, %full_10s %full_60s %full_300s %full_total"
    max_threshold = "0.75"
}
pressure io {
    format = "%some_10 %some_60 %some_300 %some_total, %f10 %f60 %f300 %ftotal
    max_threshold = "0.5"
}

Alternative: Leave out the some_ part of the variables in pressure cpu.
With pressure io analogous to pressure memory.
I don’t understand the PSI enough to know whether the max_threshold should be applied to the some, the full values, to both or whether two values would be used.

P.S

An additional, orthogonal possibility would be writing mem instead of memory.

[Columbus240]

In my opinion A is easy to read, but uses a lot of lines. It is a bit convoluted when having to determine how the status line will look like, because the order has to be kept in mind as well. An advantage is, that each of these blocks can be coloured red separately, each with a possibly different threshold.
Disadvantage is, that it is not easily possible to reach an ordering like "%memory_some_10 %memory_full_10 %memory_some_60 %memory_full_60", without shenanigans defining a block twice (which I don’t know whether and how they work).
I prefer the third variant of the variable names here, because it is very much like the syntax of load.

I prefer the structure of C with variable names of the type %full_10s. As in the load block, the time is given with an unit. In my opinion the sec suffix would make the names too long, the avg variant is not related enough to load and the f10 variant is not intuitive enough (it is not similar enough to any commonly used schemata) (I think of a 10-bit float here, being reminded of Rust’s syntax).
Disadvantage here is, that the following order of variables can’t be reached without some tricks: %cpu_some_10 %memory_some_10 %io_some_10 %cpu_some_60 %memory_some_60 %io_some_60 ….

B needs very long variable names, but is most flexible, concerning the order of the variables.
If flexibility is a major concern, I’d use B, with sensible variable names. Maybe using a scheme like %cpu_some_10s.

If new values get added to the PSI or some get removed, there is no big difference in difficulty of adjusting the configs.

[Airblader]

I'm a bit concerned with having variable variable names – that's not a concept we currently have in i3status, AFAIK.

[Columbus240]

I don’t quite understand what you mean. I didn’t mean the many different variable names to all be possible, but to use only one of the different possible variable names in the implementation. I wanted to give many different examples.

[Airblader]

Maybe I'm misunderstanding, but when I see %avg10 %avg60 %avg300 in a configuration I assumed this means either

1. We need to have a lot of variables (avg10, avg20, avg30, …) or
2. We need the name to be dynamic (parse "avg" + some number that is used as an argument)

[Columbus240]

Ok, now I see what you mean. It is option 1, but the avg20, avg30 aren’t needed, because the PSI only has avg10, avg60 and avg300. As with load average, the number of variables is finite. Just a little bigger.
In variant C I listed all variables that the PSI contains, twenty in number.

[Airblader]

Alright, thanks! Out of the three options I also think I prefer C, which seems to be what you prefer as well.

@stapelberg What's your thought on this? I know you're not very big on other similar things, but this information does sound fairly useful.

[stapelberg]

No doubt PSI is useful, but I had been looking at it from a server angle thus far, not so much for interactive desktop systems.

One thing that seems relatively clear from reading this issue is that PSI is bleeding edge and not well-understood yet.

I would recommend to show PSI through an external wrapper script (happy to accept it into contrib/ if desired) until we learn which parts of it are useful and how to best expose them to users.

Accepting any code for PSI into i3status itself seems premature at this point — we’d end up having to support it indefinitely, and I’d like to ensure we know our way around PSI before we do that.