Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4231 Post by saintless »

Hi, Andres.

Thanks, it seems like a bug in Jwm version when booting porteus-boot without persistent, then making some changes like apt-get update, then creating new save file changes.dat and trying to reboot. I get the same problem described from you.
I will try to find and post fix soon. I have to find and compare all related files in OpenBox version to see if they have some differences. Unfortunately obshutdown does not work well with Jwm version and I can't use it.

Edit: It works well after fresh boot (no extra changes or only system settings changed), create save file and reboot just after that.
For some reason having more changes to copy in /mnt/live/memory/images/changes-exit freezes the copy process and wmreboot script can't finish the job.

Edit2: Not a bug after more testing. Andres, it just takes more time for copying all the changes in new created changes.dat. For example simple apt-get update will copy inside around 105Mb and it takes 4 minutes on my machine.
Just let it finish and reboot will continue. And do not try to reboot again or do something else after click on Reboot button. The system will freeze trying to execute several reboots.

Toni

User avatar
atv
Posts: 27
Joined: Wed 16 Nov 2011, 15:44
Location: Tambo, Ecuador

#4232 Post by atv »

Thanks, Toni; In my system it took approximately 20 minutes.... In these older and slow internet connections, you need patience.

regards, Andres

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

used RAM calculation change found htop 2.0.1 vs htop 1.0.3

#4233 Post by mcewanw »

Well I may indeed be stupid or daft (or competitive) as it seems to have been suggested, and the htops are in fact identical but somehow work differently in MintPup and XeniaDog. However, I don't think so in this case. I have now read some of the htop source code and believe the following (note that I'm still checking this and will revise the findings if necessary; I have to reinstall Xenial and get its wireless working again to download htop again):

SUMMARY (in terms of /proc/meminfo stats):

The MAJOR increase in htop report in latest htop versus older one is that /proc/meminfo/Shmem is being added to the UsedMem total (though effect is slightly reduced since SReclaimable is being subtracted). Shmem is relatively large...

According to htop 2.0.1: usedMem = TotalMem - FreeMem - Buffers - Cached - SReclaimable + MemShared

whereas for htop 1.0.3: usedMem = TotalMem - FreeMem - Buffers - Cached

REMEMBER to divide answers by 1024 if converting from KiB to MiB etc.

EDIT: the new free and top in Xenial match the new htop, by the way, in terms of the /proc/meminfo stats they display - though 'usage' is displayed without shmem added and with Sreclaimable and SUnreclaim (I think) subtracted (as part of buff/cache) as far as I remember. Note that buff/cache in Xenial free and top includes Sreclaimable (and, I deduced via calculation only, SUnreclaim). I should really check with the new free/top source code, but too busy to bother now. SUnreclaim would be a difference (since not used in new htop) and dubious one, so maybe I'll check the free/top source code later... EDIT2: Done. See my next post.

EXPLANATION:

htop version 2.0.1

https://github.com/hishamhm/htop/blob/m ... cessList.c

or can download the sourcefile as tar.gz from main htop download page.

The following are the values used from /proc/meminfo (from lines 655 to 675 of above function source code):

MemTotal becomes totalMem
MemFree becomes freeMem
Cached becomes cachedMem
Buffers becomes buffersMem
MemShared becomes sharedMem
SReclaimable becomes sreclaimable

Calculation done in line 640 function LinuxProcessList_scanMemoryInfo

line 683: usedMem = totalMem - freeMem
line 684: cachedMem = cachedMem + sreclaimable - shmem (in version 1.0.3 cachedMem is left as Cached value; i.e. sreclaimable is not added and shmem is not subtracted)


In linux/Platform.c

line 203:

usedMem -= buffersMem + cachedMem (i.e. usedMem = usedMem - buffersMem - cachedMem)

where cachedMem = cachedMem + sreclaimable - shmem (where shmem is sharedMem)



htop version 1.0.3

The program isn't broken into different platforms so looking at source code for function ProcessList.c:

same /proc/meminfo stats used can be found declared from lines 898 to 917 (much the same as for htop version 2.0.1 but SReclaimable not being used.

but from line 923, htop 1.0.3 calculates usedMem simply as:

usedMem = totalMem - freeMem

and leaves Cached (cacheMem) as provided by /proc/meminfo (i.e. doesn't add sreclaimable or subtract shmem).

htop 1.0.3 later recalculates cacheMem in MemoryMeter.c thus:

line 31: usedMem -= buffersMem + cachedMem; (i.e. same as in htop 2.0.1 but remember that cachedMem here does not add sreclaimable nor subtract sharedMem)

William
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#4234 Post by mcewanw »

Downloaded 'free utility' source code from http://packages.ubuntu.com/xenial/procps

In 'free utility' source code sysinfo.c:

kb_main_total is /proc/meminfo/MemTotal
kb_main_free is /proc/meminfo/MemFree
kb_page_cached is /proc/meminfo/Cached
kb_main_buffers is /proc/meminfo/Buffers
kb_main_free is /proc/meminfo/MemFree
kb_slab is /proc/meminfo/Slab, which, I believe I read somewhere, is same as SReclaimable+SUnreclaim in /proc/meminfo
kb_main_shared is /proc/meminfo/ShMem

RAM used calculation is from lines 706:

kb_main_cached = kb_page_cache + kb_slab;
kb_swap_used = kb_swap_total - kb_swap_free;
kb_main_used = kb_main_total - kb_main_free - kb_main_cached - kb_main_buffers;

which is same thing therefore as:

free utility RAM used

= MemTotal - MemFree - Cached - Buffers - Slab

= MemTotal - MemFree - Cached - Buffers - (SReclaimable + SUnreclaim)

EDIT: Found a nice link about more of this kind of stuff...

https://blog.famzah.net/2014/09/22/know ... ory-usage/

William

EDIT2: Personally, I think the htop calculation (which doesn't use SUnreclaim) is slightly better, since how can unreclaimable memory be subtracted since it is used memory? So I think SUnreclaim value should be added back onto 'free utility' used statistic to give a more realistic report. But what would I know?
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#4235 Post by saintless »

According to this post the thread stays open as a community project:
mcewanw wrote:As I say, all dogs are community projects; no-one can ask for that work to be locked or deleted without agreement from the other contributors.

backi
Posts: 1922
Joined: Sun 27 Feb 2011, 22:00
Location: GERMANY

#4236 Post by backi »

Know i do repeat myself !
Hi Toni !

It`s a pleasure to see you back in Town ! :D :D :D
NOT kidding........

So Let`s praise the Lord ......Halleluja....!


Regards !

Post Reply