Re: diskless system ohne swap

From: Marc Santhoff <M.Santhoff(at)t-online.de>
Date: Thu, 29 Apr 2004 20:27:57 +0200

Am Do, den 29.04.2004 schrieb Oliver Fromme um 11:12:
> Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > [...]
> > 128M ist aber auch nicht so sehr viel für X.
>
> Sollte aber eigentlich genügen.
>
> > Mein XFree86 Prozess belegt z.B. 217M - und da ist der OS Bedarf
> > noch nicht mit drin.
>
> Je nach Graphikkarte mappt der XFree86-Prozeß den Video-RAM
> der Karte in sein Prozeßimage, manchmal sogar mehrfach mit
> unterschiedlichen Alignments. Bei einer Karte mit 32 Mbyte
> Video-RAM kann es durchaus passieren, daß diese Mappings
> 128 Mbyte ausmachen. Dadurch kann der Prozeß in »ps« und
> »top« sehr groß erscheinen, aber in Wirklichkeit belegt er
> nicht annähernd soviel tatsächlichen RAM.

Also meine Angaben stammen von top, da konnte ich zugucken, wie der
Speicher gefressen wird, bis es knallt. Woher bekommt man denn
zuverlässige bzw. realistische Werte?

> Das Caching von Bitmaps sollte (wiederum je nach Karte und
> deren Treiber) im Video-RAM der Graphikkarte erfolgen und
> nicht unbedingt im Hauptspeicher.

Nun ja, die Hardware in diesem Fall ist eine winzige (3,5" Format)
Hauptplatine mit Geode 300 MHz und Onboard-Grafik - shared memory
natürlich. Hoffentlich wird nicht nochmal parallel gemapped.

Wobei das auch solche Sache ist, der VESA-XServer schafft es nicht, den
Speicher als erstes zu löschen sondern macht ein quietschbunten Schirm
oder zeigt Artefakte vom letzten Programmbild. Dafür suche ich noch nach
einer Lösung ...

> > > -Andreas,
> > > ... der meint, dass ein X-Terminal mit 128 MB auskommen muesste
>
> Das meine ich auch -- mit der richtigen Graphikkarte.
>
> Meiner hier belegt aktuell ca. 40 Mbyte. Das ist mit einer
> Matrox MGA G400 (AGP) Mit XFree86 4.2.0 bei 1440 × 1080 Pi-
> xeln in Truecolor, wobei ein Browser geöffnet ist (Opera),
> Acrobat-Reader, und ca. 20 Terminal-Fenster (12 jterms und
> ein paar xterms). Meine typische Arbeitsumgebung halt.

Die ganze Sache ist ja auch noch im Wachstum, z. Zt. geht ein Teil des
Hauptspeichers für die Garfik weg (weiß garnicht, wieviel) und 8 MB für
/var (stand noch auf default).

Jetzt nach der ganzen Aktion habe ich die Testdatenmenge reduziert und
es sind aktuell (laut top) 93 MB von 128 MB frei und 10 MB Buffer.
Allerdings direkt nach dem Start, die Werte schrumpfen noch ein bischen
während des Betriebs.

Damit kann ich leben, vor allem wo im Programm selbst noch
Optimierungsspielraum schlummert.

Wichtig ist nur, eine ungefähre Einschätzung zu haben, wann es eng wird.
Und natürlich für den Fall, daß es doch rummst, die Daten in Sicherheit
zu bringen. Deswegen will ich natürlich immer noch dafür sorgen, daß das
Betriebssystem optimal auf diesen Einsatzzweck eingestellt ist.

Gruß,
Marc

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 29 Apr 2004 - 20:37:31 CEST

search this site