Date: Sun, 08 Oct 2017 20:01:20 +0000 From: bugzilla-noreply@freebsd.org To: xfce@FreeBSD.org Subject: [Bug 219155] [PATCH] x11/xfce4-taskmanager fix free mem calculation Message-ID: <bug-219155-28711-GK1pNaGCWw@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219155-28711@https.bugs.freebsd.org/bugzilla/> References: <bug-219155-28711@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219155 --- Comment #6 from Guido Falsi <madpilot@FreeBSD.org> --- (In reply to rozhuk.im from comment #3) > I discuss "free" VS "free+++": > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211432 >=20 I'm sorry but your reasoning is simplistic, and not any more correct than t= he 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 can= not be divided in "free/used". There are more conditions. My personal opinion is that any software which tries to simplify the VM sys= tem 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" (=3D=3D Active), "definitely available" (=3D=3D Free), = "half and half, may be reclaimed if really needed, but I can't promise" (=3D=3D Inact= ive + Laundry + Wired + Buf (that is, the rest)). But even this kind of simplification hides a huge amount of complexity which is anyway working be= hind the scene. While the "free" memory pool is available for immediate usage by applicatio= ns, 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 reclaime= d 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, whic= h is the actual reason why that memory is not reclaimed as soon as it is release= d 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 memo= ry and a bit inactive and wired pool, launch a program and see it work fine ev= en 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 Fr= ee (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 n= eed more detail I use top. An interesting idea could be to teach xfce4 task manager to actually show t= he same information top is showing . >=20 > patch-src__task-manager-freebsd.c - is freebsd specific file. Correct, sorry, my mistake, I did not notice this detail. >=20 > 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=3D217241 I'll take a better look at this. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219155-28711-GK1pNaGCWw>