Created attachment 182426 [details]
correct freemem calculation
Current taskmanager display free mem as: Inact + Wired + Free.
This is not correct because applications cant use mem from Inact and Wired.
Also there missed patch from my prev bug report:
Created attachment 185589 [details]
correct free mem and swap space calculation
It's not completely true that inactive, wired and buffer memory is not available to applications, in case of memory pressure some of that RAM can be reclaimed.
In your description you talk about wired memory, but in the patch there's no trace of wired, only buf memory though.
As a further note in head we now also have "laundry" memory which further complicates the accounting.
That said it all boils down to what you are actually trying to measure.
The main point though is that in the ports tree we are just porting software and are not supposed to change their logic, unless that's strictly needed to have it work in FreeBSD.
So, if you think this software needs to account for memory in a different way you should report this upstream as a bug there, but diverging in functionality from the upstream in the FreeBSD port is not the correct way.
That is unless I'm missing something in your patch.
My opinion is that your patch should go upstream, and anyway needs refinements to account for the finer details of memory subsystem.
We should anyway #ifdef the code specific to FreeBSD, or otherwise go with the generic code the upstream provides.
I discuss "free" VS "free+++": https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211432
I cant be sure that non free (inac...) become to free in case of memory pressure.
patch-src__task-manager-freebsd.c - is freebsd specific file.
patch-src_process-tree-view.c - patch that prevent crash on process kill, that not come to upstream for some reasons that I cant understand.
(In reply to rozhuk.im from comment #3)
patch-src_process-tree-view.c it already reported to upstream for a while!
(In reply to Olivier Duchateau from comment #4)
sorry for misunderstand
(In reply to rozhuk.im from comment #3)
> I discuss "free" VS "free+++":
I'm sorry but your reasoning is simplistic, and not any more correct than the present implementation, which is not correct either.
> I cant be sure that non free (inac...) become to free in case of memory
The point is in the Unix and Unix like OS Virtual Memory systems memory cannot be divided in "free/used". There are more conditions.
My personal opinion is that any software which tries to simplify the VM system in "free vs used" memory is misguided from the start. Memory should always be represented distinguishing the various category (in FreeBSD 12 Active, Inactive, Laundry, Wired, Buf, Free). At most you could simplify it to "definitely in use" (== Active), "definitely available" (== Free), "half and half, may be reclaimed if really needed, but I can't promise" (== Inactive + Laundry + Wired + Buf (that is, the rest)). But even this kind of simplification hides a huge amount of complexity which is anyway working behind the scene.
While the "free" memory pool is available for immediate usage by applications, only the "Active" pool is really definitely in use. The rest of the ram can be in various conditions. Even "wired" memory held by kernel could be reclaimed at any time. (NOTE: wired memory includes the ZFS ARC memory, if using such filesystem, and ZFS will free ARC memory in case of memory pressure)
I agree with you that reclaiming of Active or wired memory takes time, which is the actual reason why that memory is not reclaimed as soon as it is released by the application using it, why spend cicles to reclaim it if it can be done later? Often this lag is long enough for the kernel to return OOM condition to a userland program trying to allocate memory.
But the opposite condition is also true. You can have almost zero Free memory and a bit inactive and wired pool, launch a program and see it work fine even if it uses much more ram than the Free pool has, because the kernel releases memory from the other pools.
So, if you simplify ram to only two categories (free/not free) you get one big lie anyway. You can choose in which direction you want the lie to go, buut it will never be accurate.
To wrap up it all boils down to what you want to measure and to a quest of consistency. What are doing most programs reporting free/not free memory as if it was that simple? You want only free pool memory accounted as free, which could be reasonable, but is not what most programs are doing.
To wrap up, I'll review your patch again, and check what some other memory graph software is doing, but I'm not sure what the correct calculation is. I can't promise I'll implement it exactly the way you ask for.
There is no definitive and correct way to simplify the 6 states the FreeBSD VM uses to only 2.
I'll add an example, right now I have this condition in top:
Mem: 835M Active, 578M Inact, 60M Laundry, 1624M Wired, 7745K Buf, 4671M Free
(high wired is due to me using ZFS)
I'm running conky on this system and it reports 2.46 GiB as used memory.
xfce taskmanager reports 2.7 GiB used.
Your accounting would require them to report more than 3 GiB used, which is definitely too much.
In my experience, conky accounting is good enough for desktop usage, if I need more detail I use top.
An interesting idea could be to teach xfce4 task manager to actually show the same information top is showing
> patch-src__task-manager-freebsd.c - is freebsd specific file.
Correct, sorry, my mistake, I did not notice this detail.
> patch-src_process-tree-view.c - patch that prevent crash on process kill,
> that not come to upstream for some reasons that I cant understand.
I'll take a better look at this.