Treat buffers and cache as free memory in memory free calculation - #111
Treat buffers and cache as free memory in memory free calculation#111ckuethe wants to merge 5 commits into
Conversation
Treat memory_buff_cache as free memory rather than used memory. It's not totally wrong to do this, since you can evict a lot of that with `echo 3 > /proc/sys/vm/drop_caches` and see an immediate drop in `top`, but the RPC API really should be more detailed. Fixes HarvsG#85
ckuethe
changed the title
| or None, | ||
| extra_attributes_fn=lambda system_status: { | ||
| "memory_total": system_status.get("memory_total"), | ||
| "memory_free": system_status.get("memory_free"), |
There was a problem hiding this comment.
do we want to correct this as well, or is it helpful to have?
There was a problem hiding this comment.
Maybe we could report
"memory_free": system_status.get("memory_free"),
"memory_buffer_and_cache": system_status.get("memory_buff_cache"),
There was a problem hiding this comment.
I'd support reporting memory_buffer_and_cache separately, for those who care. It's not something I'd use. I'm not sure that I'd use the actual values; percentages are more useful to me, but it wouldn't hurt to expose.
What do you think about:
- memory_total -> memory_total
- memory_free -> memory_free
- memory_buff_cache -> memory_buffer_and_cache
- memory_buf_cache + memory_free -> memory_available
- memory_total - memory_available -> memory_used
The first 3 are reported unchanged because that's what the API says. The next two are computed, but feel more meaningful to me. If I had a less capable router, I might care more about exactly how many KB of memory are free/used, but on the Slate AXT-1800 percentage is more useful.
Yes, I could compute this in homeassistant, but I think it's nicer to expose the numeric values and percentages.
There was a problem hiding this comment.
Yes, I think all of that is fair. Keep them as extra_attributes, that means that they are not stored and those that are interested can turn them into sensors with templates.
|
@ckuethe |
|
Now that my HA instance with this integration is behaving better I'll have another look at it. Instead of using templates which adds extra work for the user, I'd rather send the values - perhaps as diagnostics - which can be easily enabled or disabled in the UI. |
|
Good idea, please make some disabled by default |
|
I think the diagnostic category is disabled by default, but it's easy to enable at runtime. If not, there are other examples of that behavior I can reference. |
|
|
updated to latest |
- Load averages of exactly 0 made the sensor go unavailable: the old `... and la[i]` short-circuits on the falsy 0. Use an explicit conditional so a genuine 0.0 is reported (HarvsG#152). - Treat buffer/cache memory as available when computing memory usage, matching how Linux reports free memory, and expose memory_buff_cache / memory_available / memory_used attributes (HarvsG#111). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2 participants
Treat memory_buff_cache as free memory rather than used memory. It's not totally wrong to do this, since you can evict a lot of that with
echo 3 > /proc/sys/vm/drop_cachesand see an immediate drop intop, but the RPC API really should be more detailed.Tested on Slate AXT-1800... guess when I restarted HomeAssistant to pick up the change.
Fixes #85