Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

[Christoph Rohland <cr@sap.com>]

Andrea Arcangeli <andrea@suse.de> writes:

> Said that I heard of real world programs that have a .text larger than 2G

=:-O

> I know Oracle (and most other DB) are very shm intensive.  However
> the fact you say the shm is not locked in memory is really a news to
> me. I really remembered that the shm was locked.

I just checked one oracle system and it did not lock the memory. And I
do not think that the other databases do it by default either.

And our application server doesn't do it definitely. And it uses loads
of shared memory. We will have application servers soon with 16 GB
memory at customer sites which will have the whole memory in shmfs.

> I also don't see the point of keeping data cache in the swap. Swap
> involves SMP tlb flushes and all the other big overhead that you
> could avoid by sizing properly the shm cache and taking it locked.
> 
> Note: having very fast shm swapout/swapin is very good thing (infact
> we introduced readaround of the swapin and moved shm swapout/swapin
> locking to the swap cache in early 2.3.x exactly for that
> reason). But I just don't think DBMS needed that.

Nobody should rely on shm swapping for productive use. But you have
changing/increasing loads on application servers and out of a sudden
you run oom. In this case the system should behave and it is _very_
good to have a smooth behaviour. 

Customers with performance problems very often start with too little
memory, but they cannot upgrade until this really big job finishes :-(

Another issue about shm swapping is interactive transactions, where
some users have very large contexts and go for a coffee before
submitting. This memory can be swapped. 

Greetings
		Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/