Mikor a legfrissebb kernelre frissítjük a rendszerünket, két VM kód között választhatunk. Az egyik Andrea Arcangeli által írt kód (ez van most a stabil kernelben), és a másik a Rik van Riel féle kód. Arcangeli egy levelet küldött a napokban a kernel listára melyben ez áll:
"Ne használd a 2.4-es kerneleket azelőtt, mielőtt ezt a patchet alkalmaznád".
A kérdéses patch a vm-33.gz névre hallgat. Ezt a patchet Andrew Morton kisebb darabokra szedte, hogy könnyebben be lehessen illeszteni a jelenlegi kernelbe.
A másik jelenleg elérhető VM kód a Riel féle VM kód. Riel erről a következőket mondja:
"Ennek a kódnak a segítségével egy sokkal robosztusabb és flexibilisebb VM alrendszerhez juthatunk, és amelynek egyidejűleg a kódja sokkal tisztább."
Ma megjelent a rmap-12i, amely Marcelo Tosatti 2.4-es kernelfáján alapul. Az -rmap VM jelenleg Alan Cox -ac patchének része.
Mivel az AA (Andrea Arcangeli) féle VM alrendszer a 2.4.10 óta van jelen a stabil kernelben, joggal feltehetjük a kérdést, hogy akkor eddig egy rossz kernelt használtunk (a kérdést többen is feltették)?
Álljon itt egy levélváltás ebben a témában:------------------------------------------------------------------
From: Andrea Arcangeli
Subject: vm-33, strongly recommended
[Re: [2.4.17/18pre] VM and swap - it's really unusable]
Date: Wed, 10 Apr 2002 01:36:09 +0200
I recommend everybody to never use a 2.4 kernel without first applying this vm patch:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/ 2.4.19pre5/vm-33.gz
It applies cleanly to both 2.4.19pre5 and 2.4.19pre6. Andrew splitted it into orthogonal pieces for easy merging from Marcelo's side (modulo -rest that is important too but that it's still quite monolithic, but it's pointless to invest further effort at this time until we are certain Marcelo will do its job and eventually merge it in mainline):
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/ 2.4.19pre5/
So far a first part of those patches is been merged into mainline into pre5 (not any previous kernel, if you've some problem reproducible with pre4 pre3 pre2 and pre1 or any previous kernel that's not related to the async flushing changes, I seen a bogus report floating around to Marcelo about pre1 pointing to the vm changes, it can't be the vm changes if it's pre[1234]).
This VM is under heavy stressing for weeks on my SMP highmem machine with a real life DBMS workload in a real life setup with huge VM pressure with mem=1024m and 1.2G of shm pushed in swap constantly by the kernel, performance of the workload is now very good and exactly reproducible and constant, so I recommend it for all production systems (both lowmem desktops and highend servers). Alternatively you can use the whole -aa patchkit, to get all the other critical highend features like pte-highmem, highio etc... I haven't bugreports pending on the vm patch.
Thanks,
Andrea
------------------------------------------------------------------
From: Richard Gooch
Subject: Re: vm-33, strongly recommended
[Re: [2.4.17/18pre] VM and swap - it's really unusable]
Date: Tue, 9 Apr 2002 18:07:50 -0600
Andrea Arcangeli writes:
> I recommend everybody to never use a 2.4 kernel without first applying
> this vm patch:
[...]
The way you write this makes it sound that the unpatched kernel is very dangerous. Is this actually true? Or do you really just mean "the patched kernel has better handling under extreme loads"?
Regards,
Richard....
------------------------------------------------------------------
From: Andrea Arcangeli
Subject: Re: vm-33, strongly recommended
[Re: [2.4.17/18pre] VM and swap - it's really unusable]
Date: Wed, 10 Apr 2002 02:30:06 +0200
The unpatched kernel isn't dangerous in the sense it won't destroy data, it won't corrupt memory and finally it won't deadlock on smp locks, but it can theoretically deadlock with oom and it has various other runtime issues starting from highmem balancing, too much swapping, lru list balancing, related-bhs in highmem, numa broken with += min etc... so
IMHO it is better to _always_ use the patched kernel that takes care of all problems that I know of at the moment, plus it has further optimizations. OTOH for lots of workloads mainline is just fine, the deadlocks never trigger and the runtime behaviour is ok, but unless you are certain you don't need the vm-33.gz patch, I recommend to apply it.
Andrea
