[Bug 219155] [PATCH] x11/xfce4-taskmanager fix free mem calculation

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219155

--- Comment #6 from Guido Falsi <madpilot at FreeBSD.org> ---
(In reply to rozhuk.im from comment #3)
> I discuss "free" VS "free+++":
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211432
> 

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
> pressure.

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.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217241

I'll take a better look at this.

-- 
You are receiving this mail because:
You are the assignee for the bug.