Environment:
RHLE4 (2.6.9-5.EL), i*86, powerpc

Steps to reproduce:
1. Start memtest to make the memory utilization reach a high level such as 90%
memtest:  http://carpanta.dc.fi.udc.es/~quintela/memtest/
You can use option -m to specify how many memory spaces you want to allocate for
memtest.

2. Start an fsx-linux loop
fsx-linux is a test suit provided by LTP. http://ltp.sourceforge.net/
Its config file is $LTPROOT/runtest/ltp-aiodio.part3
Here is a script snippet to start the fsx-linux loop.

while :
do
	${LTPROOT}/pan/pan -e -S -a ltpaiodiopart3 -n ltp-aiodiopart3 -l
ltpaiodio3.logfile -o ltpaiodio3.outfile -f ${LTPROOT}/runtest/ltp-aiodio.part3
done

3. The memory will reach 100%, after that, the swap utilization begin
increasing. When swap get a high level (e.g. above 90%), terminate all the
memtest processes, we can see the memory will go back to normal because kernel
frees the memeory space occupied by memtest. 

4. Then terminate fsx-linux loop, swap will never come back to normal even
though many hours have past. Looks like kernel never free the memory and swap
spaces that fsx-linux had ever occupied.

Another simpler but taking-more-time way to reproduce the swap/mem problem:
1. Run the fsx-linux loop only, it will eat up memory and swap, how long it will
take depends on how many swap/mem a test machine has.

2. Terminate the fsx-linux loop, both memory and swap never go back to normal.

Looks like this is a defect related with 2.6.9-5.EL kernel because I has never
run into this problem on 2.6.12 kernel.