QtMoko Virtual Memory

[Gennady Kupava]

В Срд, 01/09/2010 в 12:38 +0200, David Garabana Barro пишет:
> 
> It's not true for me, and it's a common misunderstanding IMHO. 

This is not misunderstanding, this is just one of questions which can't
have only one answer. For some tasks swap is good, for others - bad. I
have strong (enough for me) arguments too. Yours are strong for you, so
this is just matter of situation.

> 
> For testing, simply try to download tiles at zoom level 11, for the upper 6 
> zoom levels in tangoGPS. Better if you make it twice (moving on the map)
> 
> Without swap, it will catch all available memory, and FR will get really 
> slooooow, to the limit of appearing to hang, and even sometimes oomkill will 
> start killing some random process.
> With swap, linux can swap unused pages (other daemon pages, not tangogps ones) 
> and tangogps will continue running, and FR will be responsible. You only will 
> notice some 1-4 seconds slowdown from time to time, when pages are swapped out
> 
> swap is not only for "creating" more memory. If FR starts to massively trashing 
> pages to swap, it will really SLOW things a lot, for sure (the same is true for 
> your PC)
> 
> But it will help *a lot* to have more memory available for running apps.
> Think on swap as a place where put unused memory pages, and use real RAM for 
> currently used apps or caching files from slow uSD
> 
> Swap will *ALLWAYS* help, but will help a lot more on a limited memory device, 
> as FR
> 
> Here [1] you can read more about what I'm saying.
> 
> [1] http://kerneltrap.org/node/3202

Thanks for description, now my position:

First of all, i do not use swap on any Linux system i am using with
amount of memory >=512Mb. I even do not use swap on desktop where i have
tmpfs mounted to /tmp.

Having something published on kerneltrap is not meant to be only
possible answer, i can provide an example. Few years ago Linus believed
that moving everything to userspace is good idea and this is way to go.
Now i see everything is included to kernel (devfs vs udev, evdev vs
tslib, kms vs userspace mode switching). But i am still at the point
that every possible thing should be in userspace. I think, both points
of view very extensivly published to mailing lists and both have strong
grounds :)

First, about swap in general. IMO, swap were introduced in absolutely
different context. In 80's memory situation were completely different. 

---
now, real situations.

1. main swap problem is in it's nature. it will push to disk
less-frequently used pages from memory but use 'freed memory'. But for
me it turned out that it is impossible to predict which page is useful
which is not _in future_, and it turns out that freed memory on all
modern systems used to keep relatively useless huge disk cache. it's
question (for me) is _huge_ disk cache is better than _meduim-sized_
disk cache in many situations. note that I found that using tmpfs is
times faster than using such 'buffer' (i tested qtmoko build). having
random process swapped-out also makes system very unpredictive. you may
never know how long some application will start, this annoying for me, i
like low latency.

1a. to apply (1) to FR. imagine you have phone app in background. it got
swapped out as you did last call 8 hours ago. now, you recieve call and
what? you should wait for your app to be paged back even to start
hearing ring! considering fr sd io speed is 2.6M/s, and your app is for
example 10M, this will take 4 seconds in best case. something have to be
also discarded from memory too free up that 10M before loading your
phone app.

2. situation (2) is described in [1] you pointed. i personally face it
tons of times - some program (last were firefox and midming commander)
just run out memory due to bug or other reasons and starts incrementally
requesting swap. if you unlicky (and do not kill app in 30 seconds), you
may get your terminal and most of X be unloaded to swap, and only thing
you can do after that is hard reset. introducing limits will kill only
really useful feature of swap - being able to load something larger than
memory (3)

3. about your favorite gps application. i think it should create file
and map it to memory instead of using extreme amounts of ram to store
all data. In older day of swap not all systems had such ability. It's
strange that sometimg became 'slow'. without swap it should never become
slow, it should be just oomkilled. in fact, i do not understand this
problem very well, as i think that just next malloc should return 0, or
new throw bad_alloc.

4. swap on nand is special story. recently i saw really interesting
article on this topic (by DocScrutinizer i think). as nand has block
size of >4kb, writing (and reading) scatter pages (4k) to it may be very
slow process.

5. if your distribution is on internal NAND, it may be several times
faster to reload application from internal flash than to swap from sd.

So, i can see that i only had problems with swap and never had real
_need_ to use it.
And, because of all this i am not using swap on any of my systems,
including fr, so i have predictible and error-prone systems.

PS. I have one other thing to rant laying near this question. I can see
many statements that swap file is same to swap partition, but i can't
believe it is true - fs appears between disk and memory management
system. For magnetic hdd this means fragmentation, which can decrease
performance below anything. Also, typical modern HDD has x2 (two times)
speed difference between reading first and last sector, so it is
important to place swap to proper location (depends on HDD).

PPS. whooh, i knew that it will be long...

Gennady.