| Author |
Message |
browe
|
|
Post subject: Add zram to kernel
 Posted: 24.01.2013, 02:28
|
|
Joined: 2010-09-12
Posts: 157
Location: Canada
Status: Offline
|
|
| I'm interested in having zram added to the kernel. I've tested another kernel with zram built in and it seems to work fine. I'm interested to hear other opinions or experience with zram. |
|
|
| |
|
|
|
 |
|
slh
|
|
|
Post subject: RE: Add zram to kernel
Posted: 24.01.2013, 02:47
|
|
Joined: 2010-08-25
Posts: 962
Status: Offline
|
|
| As far as aptosid is concerned, not before it leaves staging and enters mainline proper - if at all (the concept is just stupid and incidentally not quite unlike /tmp/ on tmpfs… there's a magic trick instead, don't start swapping in the first place). |
|
|
| |
|
|
|
|
|
browe
|
|
|
Post subject: RE: Add zram to kernel
Posted: 29.01.2013, 01:21
|
|
Joined: 2010-09-12
Posts: 157
Location: Canada
Status: Offline
|
|
I agree it's a strange way to create swap space, but I'm just experimenting with different types of swap... swap partition, swap file, and swap to ram. Like you said, avoiding swap is best, and on my primary system with 8G of ram the only time I've used swap is when there's a memory leak so I've disabled swap entirely on systems that should not ever need swap.
There doesn't seem to be any other interest, so I'll let it rest. Thanks for the reply slh. |
|
|
| |
|
|
|
|
|
slh
|
|
|
Post subject: RE: Add zram to kernel
Posted: 29.01.2013, 02:56
|
|
Joined: 2010-08-25
Posts: 962
Status: Offline
|
|
Well, swapping means there isn't enough free RAM left for all the running applications. By using zram, you further reduce your available system RAM (zram contents can't be evicted/ OOMed) to keep your swap there - that's just nonsense for a 'normal' system…
Google, who have developed it, is special in this regard, as their servers have lots of dormant memory (parts of the search index which aren't currently in use; their systems have huge amounts of RAM, more than enough for just about anything - except the search index, which is larger than any amount of RAM modules could store in memory, so they have to work with chunks of it, indexes, paging, etc.). For them keeping those hot on a memory backed block device makes sense (their search index is most likely also easily compressible, which isn't the case for desktop RAM). But they are dealing with a very fine tuned system environment, where this kind of behaviour might produce a positive net effect - a normal desktop (like) system is different, it doesn't just run (parts of-) a giant database, but lots of quickly changing different stuff. Under this pretense you really want to avoid swapping (I assume your have at least 2 GB RAM, so swapping shouldn't be necessary to begin with), tips for this are tweaking vm.swappiness or even leaving out the swap partition completely (yes, swap is recommended, it's needed for hibernating, it helps online-'defragmenting' the RAM (which is necessary to retain the ability for large allocations), etc.) but on normal desktop systems, it's usually better if the OOM killer aborts processes, than to wait dozens of minutes in front of a semi-frozen system, while it swaps like hell.
This kind of functionality is developed for small and highly specialised niche use cases, comparabale to wakelocks (Android) they may make a huge difference within their particular domain - but are harmful on somewhat normal systems, which can't profit from them to begin with. |
|
|
| |
|
|
|
|
|
|
|
|
