Andrea Arcangeli: 'Ne használd a 2.4-es kernelt enélkül a patch nélkül'

 ( trey | 2002. április 10., szerda - 21:17 )

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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A cikk iroja honapokkal ezelott megirta, hogy szerinte melyik VM-el ellatott kernelt kell hasznalni. Alan Cox (es sok neves kernelhacker) szinten megirta, hogy az Andrea Arcangeli fele VM nm jo. es mivel van/volt alternativa azt lehetett volna hasznalni. ebben az esetben Linus Torvald onfejusege a hibaforras. Ugyanis a Alan Cox a Red Hat hivatalos kerneleiben NEM hasznalja ezt a VM-et. _okkal_.

Tehat ha van alternativa, akkor miert hasznaljuk a rosszabbat?

BTW: a cikk iroja nem hasznalja a kerdeses hibas VM-et. Regota az -ramp VM-et hasznalja.

;)

Az -rmap alapu VM kod bekerult a 2.5-os kernelfaba. Jelenleg ugy all a helyzet, hogy ez lesz a default VM a kovetkezo stbial kernelszeriaban. Arrol vitatkozhatunk, hogy melyik a jobb kb. olyan mint a KDE vs. GNOME, Intel vs. AMD es meg sorolhatnam. Nem hiszem hogy neked, vagy nekem kellene megitelni, hogy melyik a jobb. Nekem az utobbi valt be (tobb mint 20 szerveremen ez fut). A cikk meg tenyeket kozol, es a tenyek a kod irojatol szarmaznak. Akkor most mi a problema? =)

>Ha a "rossz"-at ugy erted, hogy hiba(ka)t tartalmaz, akkor lasd elozo hozzaszolas, es nem erdemel cikket a dolog.

Nem erdemel cikket a dolog? Ezt nem ertem. Miert csak a jot kell megirni? Ha a linuxban valami nem jo, azt meg el kell hallgatni? Ez olyan microsoftos nem?

Legyen mar onkritikank.

Egyebkent a cikk legyege nem az, hogy szerintem mi jobb, vagy rosszabb. Egyszeruen figyelmeztet egy esetlegesen bekovetkezo hibara. Most meg _mindig_ nem ertem miert baj ez. Az hogy "Ne hasznald...", "Erosen ajanlott a patch alkalmazasa...", "Hibak fordulhatnak elo...", "Ne alkalmazd prodcution rendszeren..." nem az en szambol hangzottak el. Ezt a kod iroja mondta, kuldte leveleben amit el is olvashatsz.

Akkor meg mi a baj? :-O

Egyebkent meg szerintem cikket erdemel az, hogy egy lassan masfel eve stabilnak mondott kernelben nem jo valami. Valoban hibazhat a kod iroja, hiszen o is csak emberbol van. De ettol meg joga van megtudni annak is aki mondjuk erre a kernelre egy egesz vallalat uzemeleset bizza...

Ja es meg valami. ha a hiba nem lenne sulyos, vagy esetleg olyan lenne, hogy soha nem kovetkezhet be, akkor a levelnek igy kellett volna szolni:

"Hibat talaltam a VM kodban. A hiba teoretikus, annak hogy bekovetkezik minimalis az eselye. De a hiba javitasa ajanlott ennek ellenere."

Es nem ugy kellne szolnia hogy " NE hasznald az xy kernelt enelkul a patch nelkul" - Ez nekem azt sugallja, hogy abban a kernelben valami nincs rendben. ez viszont akkor nem az en hibam =)