Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 9 hrs, 7 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 21 hrs ago - more...
| The Following 12 Users Say Thank You to maacruz For This Useful Post: | ||
aanckar, don_falcone, Estel, freemangordon, fw190, hawaii, Hurrian, nkirk, OVK, peterleinchen, reinob, stlpaul | ||
|
2011-09-11
, 10:34
|
|
Posts: 1,523 |
Thanked: 1,997 times |
Joined on Jul 2011
@ not your mom's FOSS basement
|
#132
|
Just for the record: i ALWAYS had reboot issues when enabling ramzswap device, regardless of disksize. Just uninstalled speedpatch and batterypatch (like freemangordon suggested multiple times), and tried again (propbably for the 10th time now). At least it created and initialized the device now. So now up to testing with freemangordon's proposed proc and sys values.
I used colin.stephane´s kernel packages btw, and moved swap to /dev/mmcblk1p2 (512MB size).
Remaining issue is that swapoff /dev/mmcblk0p3 takes ages and often returns the message "swapoff: /dev/mmcblk0p3: Cannot allocate memory".
Question: can we use memlimit_kb instead of disdksize_kb and provide /dev/mmcblk1p2 as backing swap, disabling swap on /dev/mmcblk0p3 as usual?
Last edited by don_falcone; 2011-09-11 at 10:44.
I used colin.stephane´s kernel packages btw, and moved swap to /dev/mmcblk1p2 (512MB size).
Remaining issue is that swapoff /dev/mmcblk0p3 takes ages and often returns the message "swapoff: /dev/mmcblk0p3: Cannot allocate memory".
Question: can we use memlimit_kb instead of disdksize_kb and provide /dev/mmcblk1p2 as backing swap, disabling swap on /dev/mmcblk0p3 as usual?
Last edited by don_falcone; 2011-09-11 at 10:44.
|
|
2011-09-11
, 11:14
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#133
|
Originally Posted by don_falcone
Do not use backing swap, it is EXTREMELY SLOW, second swap is much better in terms of performance. Of course it is much better to be on SD card instead on internal flash.
Just for the record: i ALWAYS had reboot issues when enabling ramzswap device, regardless of disksize. Just uninstalled speedpatch and batterypatch (like freemangordon suggested multiple times), and tried again (propbably for the 10th time now). At least it created and initialized the device now. So now up to testing with freemangordon's proposed proc and sys values.
I used colin.stephane´s kernel packages btw, and moved swap to /dev/mmcblk1p2 (512MB size).
Remaining issue is that swapoff /dev/mmcblk0p3 takes ages and often returns the message "swapoff: /dev/mmcblk0p3: Cannot allocate memory".
Question: can we use memlimit_kb instead of disdksize_kb and provide /dev/mmcblk1p2 as backing swap, disabling swap on /dev/mmcblk0p3 as usual?
Last edited by freemangordon; 2011-09-11 at 11:21.
| The Following User Says Thank You to freemangordon For This Useful Post: | ||
|
|
2011-09-11
, 11:21
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#134
|
Originally Posted by maacruz
Thanks for your advices, unfortunately looks like Maemo 5 is much more memory hungry than Maemo 4. For some reason I still not understand, with swap sizes > 96 M, once compcache swap becomes full, the system becomes totally unresponsive. It looks like someone is constantly moving pages in and out from swap. Most probably I will look at the issue when current CSSU campaign ceases.
It's really nice that you have finally taken on porting compcache, I was amazed nobody did it for the N900, I did it for the N8x0 and the performance improvement was very noticeable.
In the N8x0 world, having 128 MB of RAM we are using disksize=96 MB by default. As you know, disksize is not the ram used by compcache, having a compression ratio of about 1/3 usually, so in the N8x0 we usually have about 50 MB of swapped ram and 20 MB of ram used for compcache.
So, I find very curious that you are using such a low value when you have 256 MB and a much faster cpu. Really, you should be able to use disksize>128MB with no problems, so may be there is some other cause, may be too much locked ram?
Well, having a look at your sources, I'd recommend to try the same changes I did in ramzswap_drv.h , increase max_zpage_size_nobdev to PAGE_SIZE/8*7, and do not setup a backing device (the code is really inefficient).
|
|
2011-09-11
, 12:10
|
|
Posts: 1,523 |
Thanked: 1,997 times |
Joined on Jul 2011
@ not your mom's FOSS basement
|
#135
|
Originally Posted by don_falcone
That's also solved.
Remaining issue is that swapoff /dev/mmcblk0p3 takes ages and often returns the message "swapoff: /dev/mmcblk0p3: Cannot allocate memory".
Last edited by don_falcone; 2011-09-11 at 12:14.
| The Following User Says Thank You to don_falcone For This Useful Post: | ||
|
|
2011-09-11
, 13:34
|
|
Posts: 462 |
Thanked: 550 times |
Joined on Sep 2008
@ Moscow
|
#136
|
so after more tests and long uptimes i've finished up with
swappiness=30
page-cluster=5
vfs_cache_pressure=110
dirty_background_ratio=5
disksize_kb=81920
Next step is to test it with BFS...
swappiness=30
page-cluster=5
vfs_cache_pressure=110
dirty_background_ratio=5
disksize_kb=81920
Next step is to test it with BFS...
| The Following 5 Users Say Thank You to 412b For This Useful Post: | ||
 |
|
2011-09-11
, 19:44
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#137
|
Originally Posted by freemangordon
Some sort of OT question, but I do not get it:
Do not use backing swap, it is EXTREMELY SLOW, second swap is much better in terms of performance. Of course it is much better to be on SD card instead on internal flash.
what is the difference of backing swap and second swap?
I do understand that enabling another swap (after the first) will just give some more amount of swap, if first one overflows. Right?
And the prority of first enabled swap is always higher (or use swapon with option -p 32767, enhanced busybox).
So where is the difference of backing/second?
| The Following User Says Thank You to peterleinchen For This Useful Post: | ||
|
|
2011-09-11
, 20:00
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#138
|
Originally Posted by peterleinchen
Backing swap is a feature of Compcache. Compcache has some code to send pages that compress rather badly to an user-chosen 'backing' swap, which in fact doesn't differ from normal swap space in any way. By using a backing swap, you can get more out of your RAM since only the good compressible pages will be in-memory. However, it appears that the code used to do this is rather inefficient, and therefore it is recommended to not use this feature.
So where is the difference of backing/second?
Setting a second swap behaves like you would expect it to do: when the first one gets full, the second one will be used (if you haven't changed the swap space's priority, that is).
| The Following 7 Users Say Thank You to iDont For This Useful Post: | ||
|
|
2011-09-12
, 08:18
|
|
Posts: 1,523 |
Thanked: 1,997 times |
Joined on Jul 2011
@ not your mom's FOSS basement
|
#139
|
Originally Posted by freemangordon
Thanks for that bit. Is there a way that busybox' swapon would include swap priorities in a future update? That way we could omit the swapoff/swapon workaround.
Do not use backing swap, it is EXTREMELY SLOW, second swap is much better in terms of performance. Of course it is much better to be on SD card instead on internal flash.
EDIT: There's the mount package, supportingly with priority support for swap.
EDIT2: Said mount package has unmet python dependencies on my device. Bummer.
Last edited by don_falcone; 2011-09-12 at 19:58.
|
|
2011-09-23
, 20:51
|
|
Posts: 1,101 |
Thanked: 1,184 times |
Joined on Aug 2008
@ Spain
|
#140
|
Originally Posted by freemangordon
Ok, so let's bump the relevant threadEDIT:
And maybe it is better to continue compcache conversation on its dedicated thread.
Originally Posted by freemangordon
I think you are wrong and your fears are irrational (no offense intended), and I think they are causing more harm than good, for the reasons I'll lay below:It was me who insist compcache statistics to be disabled because of performance reasons (there are several spinlocks involved as you may see in source code which COULD result in performance loss). Instead of enabling stats for general public, I think it is better to just rebuild module from compcache thread with stats enabled and test with it.
First, effectively, there is a spin lock involved in each stat64 operation, but why is it there? Because compcache 0.6.2 supports several ramzswap devices, and needs to protect the stat operations of one device from the others.
If you look at the compcache 0.5.5 sources, you'll see that there is no spin lock at all, and what is more, the mutex held in ramzswap_write() is freed before all stats operations.
So, having just one ramzswap device, and I can't see why anybody could want to have more than one in the N900, there can't be slowdown at all.
Second, even if you have more than one ramzswap devices, all stat operations are just integer additions. How much will have one process to wait for another to perform an integer addition?. A microsecond?, and that's within a page operation which requires either compress or decompress no less than 4 KB.
Third, you talk about swap trashing, but not having stats prevents anybody from knowing what's going on inside ramzswap.
Finally, you recognize we have much bigger issues here, with a much bigger impact than a few microseconds from a lonely spin lock, where we would benefit from any information available to find and fix them. The more peope is able to gather information, the more chances that this gets fixed. By asking me, and everybody else, to build ourselves the modules, you are just putting blocks in the road.
So, I strongly advocate for enabling stats, which we have been using in the much slower N8x0 with no problem since I started this project. Believe me, it is a feature you want there.
Originally Posted by freemangordon
You say that swap trashing happens when ramzswap is full but that doesn't match my observations. I still don't know if it is swap trashing or constant page swapping (no stats), or what kind of memory fighting is going on, but it happens much before ramzswap is full. And if you find which exactly kernel parameter causes swap trashing when RAM/compcache is full I think all of us will say BIG thank you.
With ramzswap active and some memory pressure (just microb and opera), I observe that:
- the amount of free memory is much bigger than with normal swap, I've seen up to 100 MB free, while with normal swap it is around 5-10 MB free
- the amount of free memory constantly oscillates against the used memory with a period of a few seconds, while the swap consumed remains more or less constan. The oscillation can be as big as 10 to 100 MB, it seems the bigger the ramzswap size, the bigger the oscillation.
I have never seen anything like that happen in the N810.
It could be the changes Nokia did into the swap code (haven't looked), or it could be memory mapping of some big files, or it could be buffers/cache pressure, or the Xorg heap (just guessing), but it seems that, as memory used for ramzswap grows, it puts pressure into freeing memory, but as free memory grows, something puts pressure for using that memory a while later, repeating a cycle.
This requires more investigation.
Originally Posted by freemangordon
And that's a reason for not being more memory efficient??? Certainly I don't understand you here.
For changing compress threshold - maybe it will have slight difference in memory consumption, but I think our major problem is swap trashing, not few megs of RAM more.
In the N8x0 world, having 128 MB of RAM we are using disksize=96 MB by default. As you know, disksize is not the ram used by compcache, having a compression ratio of about 1/3 usually, so in the N8x0 we usually have about 50 MB of swapped ram and 20 MB of ram used for compcache.
So, I find very curious that you are using such a low value when you have 256 MB and a much faster cpu. Really, you should be able to use disksize>128MB with no problems, so may be there is some other cause, may be too much locked ram?
Well, having a look at your sources, I'd recommend to try the same changes I did in ramzswap_drv.h , increase max_zpage_size_nobdev to PAGE_SIZE/8*7, and do not setup a backing device (the code is really inefficient).