Re: Performance FreeBSD - NetBSD

In <20010301115539.A52850(at)foobar.franken.de>, Harold Gutch wrote:
> On Thu, Mar 01, 2001 at 08:43:28AM +0100, Borchert, IT-IS S254, B wrote:
> > Hallo,
> >
> > gibt es eigentlich schon Erfahrungen, wie schnell Netbsd1.5 mit
> > dem neuen UVM im Vergleich zu FreeBSD4.2 aussieht ?
>
> Das nicht, aber "das neue UVM" von NetBSD hat FreeBSD schon seit
> Jahren (IIRC bekam das 4.0 von Matt Dillon gleich einige Tage
> nachdem dies das neue -CURRENT wurde, also *kram* Anfang '99).

Heul. Schluchz.

Das FreeBSD-VM hat nix mit UVM zu tun und Matt Dillon ist nicht der,
der das FreeBSD-VM designed hat.

Zur Geschichte: 4.3BSD hatte ein eigenes VM-System. 4.4BSD hat das
VM-System von Mach uebernommen.

Das Mach-basierte VM in 4.4BSD war a) krueckelangsam und b)
fehlerhaft, o.a. hat es Pages beim swappen geleakt. NetBSD hatte
darueberhinaus noch Macken, dass die Maschine mit einigen mmap() -
Operationen komplett in die Knie gezwungen werden konnte, so in der
Art 10 Sekunden Antwortzeit auf Interrupt. Bei voller CPU-Last
natuerlich.

John Dyson hat fuer FreeBSD-2.0-3.x das Mach-VM repariert (im
Bugsinne) und hat es mit den Nutzungdaten, die ihm bei seiner Arbeit
mit groesseren Datenbanken zur Verfuegung standen, getunt. Man muss
dazu wissen, dass er die meiste Zeit fuer Oracle gearbeitet hat. Matt
Dillon hat in John Dysons Sinne weitergearbeitet.

NetBSD hat erst in seinem Mach-VM ein paar Sachen gefixt und dann
komplett auf das 4.3BSD VM zurueckgespult. Die konkreten Bugs wurden
gefixt und die echten Macken wo das VM-System komplett trashte sind
behoben.

Nach meinen Tests ist UVM in NetBSD 1.4 aber nicht schneller als das
vorige VM in NetBSD. Verhalten bei zuviel oder zuwenig Speicher ist
immer noch nicht erkennbar schlau, es bewegt sich so auf dem Niveau
von Linux-2.2, weit unterhalb von FreeBSD.

FreeBSD hingegen ist fuer meine Anwendungen immer noch klar der
Renner. Die Art und Weise wie sich FreeBSD von Ueberlastung erholt
und wie clever es ist, die Sachen moeglichst lange drinzubehalten, die
man gleich wieder braucht ist immer noch weit vorne.

Wer sich mal die Designbeschreibung von Matt Dillon ansieht, der weiss
auch warum das so ist.

Es spielt in der Praxis eben keine Rolle, wie schnell die
durchschnittliche Page eingepaged wird. Entscheidend ist, *welche*
Pages wann raus- und reingemoved werden. Ob das moven nun 10 CPU-%
schneller oder langsamer geschieht ist praktisch ohne Bedeutung.

Entscheidend ist, wie oft eine Page rausgeschmissen wird, die man
gleich wieder braucht. Wenn die erst mal draussen ist, ist alles
vorbei und man kann mit Optimierungen im Reinmovecode rummoschen
soviel man will, die Platte rueckt die Page so bald nicht wieder
raus.

> Ich schaetze NetBSD kostet die hohe Portabilitaet einiges an
> Geschwindigkeit, so dass es insgesamt doch ein bisschen FreeBSD
> hinterherhaengt, aber so genau kann man das eh nicht vergleichen.

Mit Portabilitaet hat das nichts zu tun. Hier sind Algorithmen
implementiert worden, die entwickelt wurden indem man konkret fiese
Dinge auf die Maschinenen geschmissen hat. Praktisch alles was das
FreeBSD VM system ausmacht steckt in C-Code, der noch nicht mal
MMU-spezifisch ist.

Etwas mehr Zurueckhaltung beim Posten falscher Informationen waere
vielleicht angebracht, zumal es hier um Credits geht. Meiner Meinung
nach verdanken wir John Dyson eine Menge von FreeBSD's Erfolg und das
sollte man nicht durch posten von Hoerensagen plattmachen. Ich waere
jedenfalls zwangslaeufig zu Linux gewechselt, als NetBSD wegen den VM
fuer mich nicht mehr tragbar war, wenn nicht FreeBSD zu dem Zeitpunkt
(1996) schon ein sehr gutes VM gehabt haette.

Martin

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org>            http://www.cons.org/cracauer/
 As far as I'm concerned,  if something is so complicated that you can't ex-
 plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message