Add support for collecting/visualizing Meminfo data #69
Conversation
src/data/meminfodata.rs
Outdated
| #[strum(serialize = "High Total")] | ||
| HighTotal, | ||
| #[strum(serialize = "High Free")] | ||
| HighFree, | ||
| #[strum(serialize = "Low Total")] | ||
| LowTotal, | ||
| #[strum(serialize = "Low Free")] | ||
| LowFree, |
There was a problem hiding this comment.
These are only applicable on 32-bit platforms with CONFIG_HIGHMEM (https://man7.org/linux/man-pages/man5/proc.5.html and https://cateee.net/lkddb/web-lkddb/HIGHMEM.html)
There was a problem hiding this comment.
Do we not want to support these fields?
There was a problem hiding this comment.
Removed the 32-bit fields.
| let reader = BufReader::new(raw_value.data.as_bytes()); | ||
| let meminfo = Meminfo::from_reader(reader)?; | ||
| let mut meminfo_data = MeminfoData::new(); | ||
| meminfo_data.add(MeminfoKeys::MemTotal.to_string(), meminfo.mem_total); |
There was a problem hiding this comment.
What happens on all of these if the kernel doesn't support it? Is the value just zero?
There was a problem hiding this comment.
The fields that have unwrap_or_default are the ones that the kernel may/may not support. If a field is absent, the value is zero.
There was a problem hiding this comment.
OK, can you just only emit them if they're present. That will also avoid creating graphs with bogus (0) values.
There was a problem hiding this comment.
Ah. If we compare a kernel with that field and a kernel that doesn't, things might get wonky.
There was a problem hiding this comment.
It's not like we already don't have to handle differences in metrics when comparing.
There was a problem hiding this comment.
We'll make a JS change where all data types can use an API to remove the 0 graphs if it is 0 for all runs, if compared.
There was a problem hiding this comment.
All legit zeros is not the same thing as all made-up zeros.
src/data/meminfodata.rs
Outdated
| #[strum(serialize = "File Huge Pages")] | ||
| FileHugePages, |
There was a problem hiding this comment.
The order of these should probably be made to follow that in the linux kernel documentation (https://docs.kernel.org/filesystems/proc.html#meminfo), as there are a few things here that are far apart (like KReclaimable) from similar metrics.
There was a problem hiding this comment.
Ok. I'll arrange them in the kernel documentation order.
There was a problem hiding this comment.
Arranged as the kernel documentation.
Collect and visualize meminfo data. aperf was used to collect data during a full kernel build. We can consider if the data in meminfo is good enough that we might skip vmstat.
aperf_report_fullbuild.tar.gz
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.