Re: FreeBSD auf Intel Atom

From: Christian Weisgerber <naddy(at)mips.inka.de>
Date: Wed, 3 Mar 2010 15:36:06 +0000 (UTC)

Bernd Walter <ticso(at)cicely.de> wrote:

> Das erste Problem ist wie viel ein Programm addressieren kann
> und das sind bei i386 4G.
> Das ist aber logischer Adressraum und nicht physikalischer.
> Im Adressraum einer Anwendung tummeln sich noch andere Dinge, wie z.B.
> ausgelagerte Seiten, Kernelseiten zum schnellen umschalten, etc.
> Nutzbar ist daher für eine Anwendung deutlich weniger.

Eben. Zuviele Leute haben eine naive Vorstellung von Speicherverwaltung;
wir sind aber nicht mehr beim C64 oder MS-DOS.

Ein Prozess läuft in einem virtuellen Adressraum. RAM wird vom
Kernel nur an den Adressen, quasi als Cache, eingeblendet, wo
tatsächlich zugegriffen wird. Und es ist sehr praktisch, wenn der
virtuelle Adressraum dünn besetzt ist. sbrk() und mmap() kommen
sich nicht in die Quere; man kann den Stack, die diversen Segmente
von Programm und Shared Libs, usw. mit minimalen Zugriffsrechten
versehen und an zufällig gewählte Adressen legen, was das Ausnutzen
von Sicherheitslücken massiv erschwert; malloc() kann Allokationen
zufällig verteilen und geschützte Bereiche dazwischenlegen...

http://www.openbsd.org/papers/ven05-deraadt/index.html

Und das alles, ohne dass man sich allzu viele Gedanken um Fragmentierung
und Kollisionen machen muss. In einem 4GB-Adressraum, der heutzutage
einfach *voll* ist, ist das alles eine Quälerei.

> Dann gibt es den physikalischen Adressraum für DMA. [...]
> Alpha Systeme hatten hierfür eine IO-MMU, die PCI-Karten einen logischen
> Adressraum zugewiesen haben, sodass man den für DMA erreichbaren Speicher
> dynamisch verteilen konnte -

sparc64 hat das selbstverständlich auch.

-- 
Christian "naddy" Weisgerber                          naddy(at)mips.inka.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 03 Mar 2010 - 16:36:20 CET

search this site