Thema: "Interface" der Pagemapping Funktion

[Svenska]

Und wenn du keinen OOM-Killer willst, darfst du halt nicht overcommitten.

Nicht ganz. Wenn ein Programm exakt so viel Speicher reserviert, wie vorhanden ist und der Kernel selbst braucht ein bisschen Speicher (z.B. für Swapping via Ethernet), dann hilft nur noch panic().

Also entweder kein Overcommitment (plus etwas Reserve, 64K sollten aber im Notfall reichen) oder ein definierter Umgang mit knappem Speicher. Linux wirft erst den Plattencache weg, dann werden die Treiber angewiesen, alles überflüssige wegzuwerfen, danach wirft der Kernel selbst ein paar interne Datenstrukturen (die man sich jedesmal neu ausrechnen könnte) weg und erst, wenn das nicht klappt, schlägt der OOM-Killer zu.

Im Ernst, für mich persönlich ist Overcommit ein Bug, dafür gibt es doch Swapping damit Speicher der zwar alloziert ist aber nicht benutzt wird nicht zwingenst den physischen RAM zumüllen muss.

Hä? Ungenutzter, aber reservierter Speicher belegt bei MAP_LAZY keinen physischen RAM.

Denn wenn gerade das Programm abgeschoßen wird, mit welchem gerade gearbeitet wurde und die Daten dann weg sind, wäre es auch egal gewesen ob der gesamte PC abgeschoßen worden wäre.

Nein. Wenn das Programm wegfliegt, ist das zwar ärgerlich, aber es trifft die anderen Programme normalerweise nicht. Und ich erspare mir den (je nach OS) langwierigen Neustart...

Gruß,
Svenska

[FlashBurn]

Nein. Wenn das Programm wegfliegt, ist das zwar ärgerlich, aber es trifft die anderen Programme normalerweise nicht.

Es ging darum, das die Daten dann höchstwahrscheinlich weg sind, von daher ist es egal, ob nun das Programm gekillt wurde oder das ganze OS nen panic() gemacht hätte. Dann lieber so, dass das Programm meldet, das kein Speicher mehr verfügbar ist und das dadurch einige Aktionen nicht klappen, aber die Daten noch gespeichert werden können.

[erik.vikinger]

Hallo,

Linux wirft erst den Plattencache weg, dann werden die Treiber angewiesen, alles überflüssige wegzuwerfen, danach wirft der Kernel selbst ein paar interne Datenstrukturen (die man sich jedesmal neu ausrechnen könnte) weg und erst, wenn das nicht klappt, schlägt der OOM-Killer zu.

Genau darin sehe ich das Problem. Wenn nur um ein paar wenige MB Overcommitet wurde mag das gehen aber grundsätzlich empfinde ich persönlich das als Bug. Speicher der vom OS zugesichert wurde muss vom OS dann auch zur Verfügung gestellt werden können ohne das der OOM-Killer eventuell kommen muss. Eben deswegen richte ich mir unter Linux trotzdem immer noch eine kleine SWAP-Partition ein, ein paar Puffer wegwerfen und andere selten genutzte Pages auslagern ist IMHO sehr viel weniger schlimm als der OOM-Killer der gerade meine stundenlange Arbeit rücksichtslos entsorgt (selbst wenn das Swapping ein paar Sekunden braucht und dabei den Rechner blockiert). Das Overcommiten von Linux ist wimre im Embedded-Umfeld mal sehr unangenehm aufgefallen weil dort eben kein Swapping verfügbar ist und das Linux plötzlich in Panic ging (Platten-Caches u.ä. gab es dort ja gar nicht) ohne das gleich ersichtlich wurde was eigentlich passiert ist weil es ja nie eine Fehlermeldung gab. Speicher der bei Bedarf entsorgt werden kann dürfte in der Gesamt-Menge des zugesicherten Speichers natürlich nicht auftauchen (oder nur zu 25% o.ä.), auf diese Weise ist trotzdem noch eine Art Overcommit möglich aber ohne das Risiko das der OOM-Killer kommen muss.

Hä? Ungenutzter, aber reservierter Speicher belegt bei MAP_LAZY keinen physischen RAM.

Aber wenn er später doch mal benutzt wird und das OS Overcommit betreibt dann kommt völlig unerwartet der OOM-Killer und das gilt es zu vermeiden. Wenn man dann nicht mehr Overcommited und MAP_NOW macht belegt dieser ungenutzte Speicher natürlich auch physischen RAM. Wenn man zum physischen RAM aber noch ein bisschen SWAP-Space dazu packt dann kann man den gemappten aber ungenutzten Speicher wenigstens auslagern (so das der physische RAM etwa den selben Inhalt hat wie bei Overcommit und MAP_LAZY).

Dann lieber so, dass das Programm meldet, das kein Speicher mehr verfügbar ist und das dadurch einige Aktionen nicht klappen, aber die Daten noch gespeichert werden können.

Dann solltest Du auf jeden Fall auf Overcommit verzichten. Und wegen der Performance am besten auch auf MAP_LAZY (außer beim Stack), das ist insgesamt betrachtet auf jeden Fall teurer als MAP_NOW. Wenn Du kein Overcommit hast und Dinge wie den Stack trotzdem MAP_LAZY mappst dann geht Dir immer etwas physischer Speicher verloren (eben die Pages die Du zwar zugesichert hast aber noch nicht gemappt wurden, das kann sehr viel werden wenn Du jedem Thread 1 MB Stack zusicherst aber diese durchschnittlich nur ein paar KB davon benutzen). Das ist zwar ärgerlich aber sichert zumindest einen stabileren Betrieb (und Du hast dann garantierten Speicher für Buffers u.ä. ). Wenn Du dann später irgendwann auch Swapping hast kannst Du ja insgesamt mehr Speicher zusichern (nämlich physischen RAM + Swap-Space) aber auch von dieser Summe geht Dir ein Teil für die MAP_LAZY-Pages verloren, aber zumindest ist Swap-Space so billig das man darüber nicht weinen muss.


Grüße
Erik


PS.: Da fällt mir gerade auf das ich mit meinen Segmenten ein Problem hab: weil es bei Segmenten kein MAP_LAZY gibt verbraucht der Stack ja nicht mehr linearen Speicher als er tatsächlich benutzt ist. Auf der einen Seite möchte ich zwar zusichern das der Stack auch mal richtig groß werden kann (bis knapp 1 GB auf der 32Bit-Version) auf der anderen Seite kann ich ja nicht für jeden Stack so viel linearen Speicher reservieren. Ich schätze darüber muss ich noch mal in Ruhe nachgrübeln.

[Svenska]

Nein. Wenn das Programm wegfliegt, ist das zwar ärgerlich, aber es trifft die anderen Programme normalerweise nicht.

Es ging darum, das die Daten dann höchstwahrscheinlich weg sind, von daher ist es egal, ob nun das Programm gekillt wurde oder das ganze OS nen panic() gemacht hätte.

Administrier du mal einen Server und habe ein Programm, welches hin und wieder durchdreht... und jedesmal das gesamte OS mit sich reißt.

Dann lieber so, dass das Programm meldet, das kein Speicher mehr verfügbar ist und das dadurch einige Aktionen nicht klappen, aber die Daten noch gespeichert werden können.

Wenn für das Programm ein malloc() misslingt und es dadurch nicht mehr weiterarbeiten kann, ist es meist auch schon für weitergehende Tätigkeiten (wie z.B. Dateiinhalt aufbereiten und in Dateien schreiben) zu spät. Ein Speicherdump des Programms nutzt dir nämlich nichts.

Das Overcommiten von Linux ist wimre im Embedded-Umfeld mal sehr unangenehm aufgefallen weil dort eben kein Swapping verfügbar ist und das Linux plötzlich in Panic ging (Platten-Caches u.ä. gab es dort ja gar nicht) ohne das gleich ersichtlich wurde was eigentlich passiert ist weil es ja nie eine Fehlermeldung gab.

Auch auf einem Router gibt es einen Plattencache (siehe "cached" und "buffered"). Die Gefahr, die du bei einem monolithischen System immer hast, sind die Treiber. Dort ein Speicherleck und du bekommst immer einen OOM, und wenn der "init" trifft auch ne panic().

Hä? Ungenutzter, aber reservierter Speicher belegt bei MAP_LAZY keinen physischen RAM.

Aber wenn er später doch mal benutzt wird und das OS Overcommit betreibt dann kommt völlig unerwartet der OOM-Killer und das gilt es zu vermeiden.

Nein, dann wird angefangen zu swappen. In dem Moment, wo Swapspace in Anspruch genommen wird, steht der Kernel unter "memory pressure" und verändert sein Verhalten. Der OOM-Killer kommt also nicht unerwartet.

Swapping ist im Übrigen so grottenlangsam, dass man es nichtmal im Ansatz benutzen will, wenn es sich nur irgendwie vermeiden lässt. Der wird also nicht in die erlaubte Übernutzung des RAMs einbezogen.

Gruß,
Svenska

[FlashBurn]

Administrier du mal einen Server und habe ein Programm, welches hin und wieder durchdreht... und jedesmal das gesamte OS mit sich reißt.

Mal davon abgesehen, dass ich genau das für das Problem von Linux halte, ich will ja eher in die Richtung Desktop als Server. Sprich auf nem Server hast du Recht aufm Desktop eher nicht.

Swapping ist im Übrigen so grottenlangsam, dass man es nichtmal im Ansatz benutzen will, wenn es sich nur irgendwie vermeiden lässt. Der wird also nicht in die erlaubte Übernutzung des RAMs einbezogen.

Ich wünschte Windows würde das so machen, ich weiß das es unter Linux so ist (jedenfalls meinen Beobachtungen nach).

[Svenska]

Okay, wann immer eine Anwendung komische Dinge tut, muss dein Kernel mit panic() reagieren.
Du kannst ja den Windows-Weg gehen und einen automatischen Neustart anordnen.

[FlashBurn]

Okay, wann immer eine Anwendung komische Dinge tut, muss dein Kernel mit panic() reagieren.

Das versteh ich jetzt mal wieder nicht

Ich dachte eher daran, das die Anwendung auf eine Anfrage nach mehr Speicher, einfach nen Fehler zurück bekommt (so wie alle Speicheranfragen in der Situation). Allerdings sollte halt immer eine kleine Reserve für den Kernel freigehalten werden.

[erik.vikinger]

Hallo,

Wenn für das Programm ein malloc() misslingt und es dadurch nicht mehr weiterarbeiten kann ....

Es gibt Programme die können mit einem fehlgeschlagenen malloc ziemlich gut umgehen, z.B. Modelsim (hab ich persönlich erlebt), wenn das während einer Simulation keinen Speicher mehr anfordern kann wird die Simulation weggeräumt aber der angesammelte Datensatz gesichert. Es kann dann zwar sein das die Simulation unvollständig ist aber zumindest ist die verbrauchte Rechenzeit (eventuell viele viele Stunden) nicht vergeudet und man kann eventuell zumindest wenigstens einen Teil der gewünschten Informationen gewinnen. Bei ordentlichen Programmen wo die Programmierer damit rechnen das ein malloc auch mal null zurück liefert funktioniert sowas recht gut, dass das bei einfachen Wald- und Wiesen-Programmen nicht so gut funktioniert ist kein Grund im OS auf eine anständige Speicherverwaltung zu verzichten.

Auch auf einem Router gibt es einen Plattencache (siehe "cached" und "buffered").

Schon klar, aber mangels eines echten Block-Devices in den meisten Embedded-Systemen dürfte da nur ziemlich wenig drin sein (die Flash-File-Systeme arbeiten oft ungecached, die wollen ja schließlich nicht den kostbaren RAM vergeuden) also bringt es auch nur wenig dort etwas weg zu werfen.

Nein, dann wird angefangen zu swappen.

Aber nur wenn es auch Swap-Sapce gibt was ja eben nicht immer zutrifft, ich schrieb ja ausdrücklich von Embedded-Systemen.

In dem Moment, wo Swapspace in Anspruch genommen wird, steht der Kernel unter "memory pressure" und verändert sein Verhalten.

Ach und wie merkt das der User? Vor allem bei einem Router? Selbst auf einem Desktop-System dürfte der durchschnittliche User kaum merken was für Befindlichkeiten der OS-Kernel gerade hat. Und es ist IMHO auch nicht Aufgabe des Users die Unpässlichkeiten des OS-Kernels zu überwachen. Es ist Aufgabe der Programme bei negativen Antworten des Kernels den User zu informieren und nachzufragen wie den nun weiter verfahren werden soll. Und es ist Aufgabe des OS-Kernels die Programme mit den Returnwerten bei Syscalls klar darüber zu informieren wie die aktuelle Lage ist.

Der OOM-Killer kommt also nicht unerwartet.

Doch, er kommt unerwartet. Selbst aus Sicht der Programme, die ja problemlos Speicher allozieren konnten, kommt der OOM-Killer unerwartet.

Swapping ist im Übrigen so grottenlangsam, dass man es nichtmal im Ansatz benutzen will, wenn es sich nur irgendwie vermeiden lässt. Der wird also nicht in die erlaubte Übernutzung des RAMs einbezogen.

Klar ist Swapping grottenlangsam aber warum soll man zugesicherten Stack der aber nicht benutzt wird und mit hoher Wahrscheinlichkeit auch nie benutzt werden wird nicht aus dem Swap-Space zusichern? Immer noch besser als wenn das Programm seine Arbeit abbricht nur weil mehr Speicher zugesichert werden soll als physischer RAM vorhanden ist.
Ich kann ehrlich nicht Deine Abneigung gegen das Swapping verstehen. Klar will man das auf jeden Fall vermeiden, z.B. in dem man genug RAM reinsteckt (ist ja heutzutage kein Problem mehr), aber dieses Konzept deswegen gleich ganz ablehnen erscheint mir einfach etwas zu drastisch. Wenn ein Programm gerade so durchläuft nur weil das OS alle anderen Programme auslagert und ich den Computer in der Zeit überhaupt nicht benutzen kann ist das in vielen Fällen zumindest besser als wenn das Programm gar nicht durchläuft. Natürlich ist das keine schöne Situation aber eben doch besser als der OOM-Killer.


Grüße
Erik

[FlashBurn]

Bei ordentlichen Programmen wo die Programmierer damit rechnen das ein malloc auch mal null zurück liefert funktioniert sowas recht gut, dass das bei einfachen Wald- und Wiesen-Programmen nicht so gut funktioniert ist kein Grund im OS auf eine anständige Speicherverwaltung zu verzichten.

Also für mich sind alle Programme die malloc() nicht auf null überprüfen fehlerhaft (haben Bugs). Da gibt es gar keine Diskussion. Denn wenn ich eh davon ausgehe das malloc() immer was zurück liefert (!= null), wozu dann überhaupt nen Rückgabewert? Zumal das Programm dann eigentlich auch auf allen Systemen hätten auffallen müssen (zwecks GPF, weil null-Pointer Zugriff).

Klar will man das auf jeden Fall vermeiden, z.B. in dem man genug RAM reinsteckt (ist ja heutzutage kein Problem mehr)

Aber bitte dazu sagen, dass das für Desktop- und Server-Systeme kein Problem ist, für Handy, Smartphone, Tablets, ARM-Netbooks usw. schon. Da kann ich den RAM leider (noch) nicht nach belieben erweitern.

Gibt es eigentlich ein bezahlbares Board (mit Bildausgabe -> VGA, HDMI, DVI ist völlig egal) mit nem Cortex-A9 (Dual), RAM-Steckplätzen und IDE- und/oder SATA-Anschlüssen?

[erik.vikinger]

Hallo,

Also für mich sind alle Programme die malloc() nicht auf null überprüfen fehlerhaft (haben Bugs).

Klar, darüber brauchen wir wirklich nicht zu diskutieren, der feine Unterschied liegt darin wie die Programme damit umgehen. Ob die einfach mit einer Fehlermeldung abbrechen (und sämtliche Arbeit wegwerfen, was IMHO keinen Unterschied zum OOM-Killer oder GPF macht) oder zumindest noch versuchen ihre bisherige Arbeit zu retten (Modelsim gehört glücklicherweise zur letzteren Gruppe).

Aber bitte dazu sagen, dass das für Desktop- und Server-Systeme kein Problem ist, für Handy, Smartphone, Tablets, ARM-Netbooks usw. schon. Da kann ich den RAM leider (noch) nicht nach belieben erweitern.

Ja, da hast Du recht. Aber in der Embedded-Klasse hat man üblicherweise auch keinen Swap-Space so das gerade dort das Overcommit zu ernsten Problemen führen kann. Im Desktop- und Server-Bereich kann man mit ausreichend RAM und mit Swap-Space die Situation mit wenig Aufwand/Kosten deutlich entschärfen.

Gibt es eigentlich ein bezahlbares Board (mit Bildausgabe -> VGA, HDMI, DVI ist völlig egal) mit nem Cortex-A9 (Dual), RAM-Steckplätzen und IDE- und/oder SATA-Anschlüssen?

klar: http://trimslice.com
Da ist der RAM zwar nicht steckbar aber dafür sind schon 1 GB aufgelötet, klar wären 2 GB schöner aber ich denke auch mit dem einem GB kann man schon recht glücklich werden. Ansonsten bin ich mir sicher das man auch pinkompatible RAM-Chips mit der doppelten Kapazität findet und mit einer kleinen Modifikation im Boot-Loader den RAM-Fun-Faktor verdoppeln kann .
Dafür sind 2 bis 6 Watt echt nicht schlecht in Anbetracht der gebotenen CPU-Power und Anschlussvielfalt (wozu auch 2 digitale Monitor-Anschlüsse gehören).


Grüße
Erik

[FlashBurn]

Was den TrimSlice betrifft, kannte ich schon, aber irgendwie bin ich zu blöd bei den Shops was zu finden, wie ich das Ding einfach kaufen kann (bzw. interessiert mich als erstes mal der Preis) und leider scheint es die noch nicht DE zu geben.
Ein OMAP-Board wäre Multimedia-technisch besser, aber ob es eher für PowerVR oder nVidia Grakas Open-Source Treiber gibt, wage ich nicht zu schätzen.

Edit::

Nach langer Suche, habe ich die Preise jetzt gefunden. Ich sag mal so wird das aber nichts mit ARM und Konkurrenz zu AMD/Intel. Viel zu teuer das Zeug (ich gucke jetzt mal nur auf den Preis und die Gebotene Leistung und lasse mal den Stromverbrauch außen vor). Für das Board, welches den SATA Anschluss hat (welcher mMn absolut sinnlos ist, da über USB realisiert und USB ist unter Tegra wahrlich kein Geschwindigkeitswunder) bekomme ich ja schon nen billig Laptop und der hat (verglichen mit der ARM CPU) wesentlich mehr Leistung.
Außerdem habe ich schon ein Tegra 2 Gerät hier (das AC100) und irgendwie gefäält mir der OMAP wesentlich besser. Zu Freescale, Marvel und Qualcomm kann ich nichts sagen, da ich von denen noch keine entsprechenden Boards und Communities gefunden haben.

[Svenska]

Administrier du mal einen Server und habe ein Programm, welches hin und wieder durchdreht... und jedesmal das gesamte OS mit sich reißt.

Mal davon abgesehen, dass ich genau das für das Problem von Linux halte, ich will ja eher in die Richtung Desktop als Server.

Linux stürzt in den seltensten Fällen komplett ab (wenn, dann sind das Treiberfehler). Wenn du also bei einem Programmabsturz das System mittöten willst, musst du mit panic() reagieren.

Schon klar, aber mangels eines echten Block-Devices in den meisten Embedded-Systemen dürfte da nur ziemlich wenig drin sein (die Flash-File-Systeme arbeiten oft ungecached, die wollen ja schließlich nicht den kostbaren RAM vergeuden) also bringt es auch nur wenig dort etwas weg zu werfen.

Der Plattencache belegt immer jeden frei verfügbaren RAM, auch bei JFFS2 oder UBIFS liegt das unterhalb des Dateisystems. Den wegzuwerfen bringt immer ein paar Pages, die man notfalls benutzen kann.

In dem Moment, wo Swapspace in Anspruch genommen wird, steht der Kernel unter "memory pressure" und verändert sein Verhalten.

Ach und wie merkt das der User? Vor allem bei einem Router? Selbst auf einem Desktop-System dürfte der durchschnittliche User kaum merken was für Befindlichkeiten der OS-Kernel gerade hat.

Naja, es wird ja nicht beliebig viel RAM vorgegaukelt, sondern einmal kann jedes Programm nur so viel RAM anfordern, wie physisch maximal möglich ist (mach mal ein dd mit bs=ramgröße) und zum anderen darf die Summe aller Anforderungen nicht den verfügbaren Speicher (inklusive Swap) überschreiten. Auf einem Embedded-Device ohne Swap heißt das, dass kein Overcommit stattfindet, trotz MAP_LAZY.

Auf einem Desktop-System merkst du sofort, wenn das System mit dem Auslagern anfängt; das dürfte aber am Scheduler liegen.

Der OOM-Killer kommt also nicht unerwartet.

Doch, er kommt unerwartet. Selbst aus Sicht der Programme, die ja problemlos Speicher allozieren konnten, kommt der OOM-Killer unerwartet.

Der OOM-Killer schlägt genau dann zu, wenn nicht mehr genug RAM+Swap verfügbar ist, um weiterzumachen. Da das die Übernutzung nur so weit geht, wie RAM+Swap (mit Reserve) vorhanden ist, passiert das ausschließlich, wenn das System unter totaler Speicherlast steht und ein Treiber im Kernel-Space noch zusätzlichen RAM möchte, der sich nicht mehr durch Sparmaßnahmen im Kernel (einschl. Swapping) beschaffen lässt.

Der OOM-Killer kommt also nur unter Speicherlast, ausgereiztem Swapspace und genau dann, wenn der Kernel selbst Speicher braucht.

Ich kann ehrlich nicht Deine Abneigung gegen das Swapping verstehen. Klar will man das auf jeden Fall vermeiden, z.B. in dem man genug RAM reinsteckt (ist ja heutzutage kein Problem mehr), aber dieses Konzept deswegen gleich ganz ablehnen erscheint mir einfach etwas zu drastisch.

Für mich ist Auslagern die letzte Möglichkeit, den OOM-Killer zu verhindern bzw. dessen Aufruf hinauszuzögern. Das klingt vielleicht etwas hart, aber inzwischen gibt es auf fast allen Systemen genug RAM, um sinnvoll damit arbeiten zu können. (Router mit 8 oder 16 MB RAM gehören nicht dazu, aber mit 32 MB lässt sich schon was anfangen. Neue Router haben meist 32 oder 64 MB.)

Wenn ein Programm gerade so durchläuft nur weil das OS alle anderen Programme auslagert und ich den Computer in der Zeit überhaupt nicht benutzen kann ist das in vielen Fällen zumindest besser als wenn das Programm gar nicht durchläuft. Natürlich ist das keine schöne Situation aber eben doch besser als der OOM-Killer.

Darum lehne ich Swapping ja auch nicht ab, sondern versuche es nur schlechtzumachen. Es ist besser als keine Lösung, aber eben niemals eine gute Lösung.

Ein OMAP-Board wäre Multimedia-technisch besser, aber ob es eher für PowerVR oder nVidia Grakas Open-Source Treiber gibt, wage ich nicht zu schätzen.

Weder für PowerVR noch für nVidia gibt es Opensource-Treiber (nouveau unterstützt nur die normalen Chips) und meine Erfahrungen mit TI OMAP sind ... mäßig. Der Upstream-Support ist in meinen Augen richtig schlecht, man muss eigentlich einen von TI bereitgestellten Kernel verwenden.Der wiederum ist nicht der aktuellste und wird auch nicht durch neue Versionen ersetzt. Außerdem sind die OMAP-Datenblätter das allerletzte. Dumm ist halt nur, dass TI wirklich gute Chips herstellt und es kaum Alternativen gibt...

Nach langer Suche, habe ich die Preise jetzt gefunden. Ich sag mal so wird das aber nichts mit ARM und Konkurrenz zu AMD/Intel. Viel zu teuer das Zeug

Richtig. Allerdings hinkt dein Vergleich: Erst die allerneusten, noch goldig glänzenden ARM-Bausteine haben hinreichend gute Performance - x86 hatte das schon vor einigen Jahren und damit genug Zeit, die Preise zu senken.

Außerdem habe ich schon ein Tegra 2 Gerät hier (das AC100) und irgendwie gefäält mir der OMAP wesentlich besser. Zu Freescale, Marvel und Qualcomm kann ich nichts sagen, da ich von denen noch keine entsprechenden Boards und Communities gefunden haben.

Ich prügel mich mit einem relativ antiken ARM9 (S3C2410@266 MHz) von Samsung, der mir ziemlich gut gefällt. Allerdings weiß ich nicht, ob Samsung auch modernere Bausteine herstellt...

Gruß,
Svenska

[FlashBurn]

Linux stürzt in den seltensten Fällen komplett ab (wenn, dann sind das Treiberfehler).

Was nebenbei gesagt auch für Windows gilt

Ich meinte aber in dem Konkreten Fall (und habe mich halt verdammt dumm ausgedrückt), das Linux mehr Server-OS ist als alles andere und deswegen auch bei bestimmten Sachen aufm Desktop nicht so das wahre ist. Dazu gibt es eine schöne Karikatur:

Weder für PowerVR noch für nVidia gibt es Opensource-Treiber (nouveau unterstützt nur die normalen Chips)

Das weiß ich, ich meinte wo es eventuell mal Opensource-Treiber geben wird. Zu PowerVR habe ich gehört, das es eventuell im Q32011 für den im 1. (??) Atom verbauten einen geben soll und was nVidia betrifft, gibt es halt nouveau und ich denke mal die haben für Tegra das Rad nicht neu erfunden.

meine Erfahrungen mit TI OMAP sind ... mäßig. Der Upstream-Support ist in meinen Augen richtig schlecht, man muss eigentlich einen von TI bereitgestellten Kernel verwenden.Der wiederum ist nicht der aktuellste und wird auch nicht durch neue Versionen ersetzt. Außerdem sind die OMAP-Datenblätter das allerletzte.

Nagut, dazu kann ich rein gar nichts sagen, da mangelnde Erfahrung. Was genau meinst du mit den Datenblättern?

Ich habe sowieso das Gefühl, das alles außerhalb von x86 eher weniger gut unterstützt ist (Mainline) und Opensource noch weniger (auch das hat ja auf x86 seine Zeit gedauert und gibt es für nVidia auch noch nicht offiziel, bei AMD ja immerhin halt offiziel).

Ich prügel mich mit einem relativ antiken ARM9 (S3C2410@266 MHz) von Samsung, der mir ziemlich gut gefällt. Allerdings weiß ich nicht, ob Samsung auch modernere Bausteine herstellt...

Die müssen auch neuere Chips haben, da ich irgendwo mal was gelesen hatte, das es auch Cortex-A8/9 SoCs von denen gibt.

[Svenska]

Linux ist für den Desktop genauso gut geeignet wie Windows für den Server, schließlich wird letzteres dafür ja teuer verkauft.

Auf einem normalen PC habe ich bisher nur einen OOM produziert, als ich "make -j64" für Qemu ausgeführt habe. Der hat mir dann den Bauvorgang abgeschossen. (Ich habe keinen Swapspace auf meinem Notebook.)

Weder für PowerVR noch für nVidia gibt es Opensource-Treiber (nouveau unterstützt nur die normalen Chips)

Das weiß ich, ich meinte wo es eventuell mal Opensource-Treiber geben wird. Zu PowerVR habe ich gehört, das es eventuell im Q32011 für den im 1. (??) Atom verbauten einen geben soll und was nVidia betrifft, gibt es halt nouveau und ich denke mal die haben für Tegra das Rad nicht neu erfunden.

Intels Poulsbo-Chipsätze für Netbooks werden unter Linux nicht gebrauchbar unterstützt, weil die Grafik von PowerVR eingekauft wurde statt selbst entwickelt. Darum macht Intel ein bisschen Druck, dass da vernünftiger Opensource-Support kommen soll. Die nouveau-Entwickler hingegen haben jeden Support verneint, den wird es aus der Ecke nicht geben.

An Open Source-Treiber glaube ich erst, wenn ich sie sehe. PowerVR hat sich bisher mit aller Gewalt dagegen gestemmt und macht das weiterhin und NVidia hat keinen Grund, weil deren Treiber einfach immer und überall funktionieren.

meine Erfahrungen mit TI OMAP sind ... mäßig. [...] Außerdem sind die OMAP-Datenblätter das allerletzte.

Nagut, dazu kann ich rein gar nichts sagen, da mangelnde Erfahrung. Was genau meinst du mit den Datenblättern?

Sowas (OMAP36xx) oder sowas (OMAP4430).

Ich habe sowieso das Gefühl, das alles außerhalb von x86 eher weniger gut unterstützt ist (Mainline) und Opensource noch weniger (auch das hat ja auf x86 seine Zeit gedauert und gibt es für nVidia auch noch nicht offiziel, bei AMD ja immerhin halt offiziel).

Naja, für x86 gibt es genau zwei zu unterstützende Plattformen (PC und Macintosh), bei ARM hat jeder Hersteller seine eigene. Das macht den Support immer etwas schwieriger.

PS: Linux kann bei mir "smooth fullscreen flash video", ich muss es nur mit dem mplayer oder VLC abspielen.

[FlashBurn]

Linux ist für den Desktop genauso gut geeignet wie Windows für den Server, schließlich wird letzteres dafür ja teuer verkauft.

Dazu kann ich auch, mangels Erfahrung, nichts sagen, aber meine Logik sagt mir, das Linux wahrscheinlich einfacher zu managen ist (von außerhalb) und deswegen besser geeignet ist (aber nicht nur deswegen).
Allerdings muss halt klar sein, dass Sachen die für einen Server von Vorteil sind, für den Desktop von Nachteil sein können.

Sowas meinst du also mit Datenblatt. Wieso sind die so schlecht? Ich frage weil ich mich ja dann auch mal damit beschäftigen will und erst dann merkt man wie gut oder schlecht eine Doku ist.

Naja, für x86 gibt es genau zwei zu unterstützende Plattformen (PC und Macintosh), bei ARM hat jeder Hersteller seine eigene. Das macht den Support immer etwas schwieriger.

Das ist genau mein Problem mit ARM, dass es keine einheitliche Plattform gibt oder zumindest sowas in der Art wie ACPI.

Ist der einzige Unterschied zw. PC und Macintosh nicht, PC noch BIOS und Macintosh nur EFI? Weil dann wäre das für mich eigentlich auch kein Unterschied mehr, jedenfalls nicht mehr lange.

[Svenska]

Allerdings muss halt klar sein, dass Sachen die für einen Server von Vorteil sind, für den Desktop von Nachteil sein können.

Das sehe ich etwas anders. Du kannst aus jedem Serversystem ein gebrauchbares Desktopsystem machen, indem du eine gute GUI draufbastelst, die mit den drunterliegenden Features umgehen kann. Andersrum wird es schon schwieriger.

Sowas meinst du also mit Datenblatt. Wieso sind die so schlecht? Ich frage weil ich mich ja dann auch mal damit beschäftigen will und erst dann merkt man wie gut oder schlecht eine Doku ist.

Mal reingeschaut? Guck mal, wie lang das Inhaltsverzeichnis ist. Das Ding ist so komplex, dass man es nichtmal im Ansatz überblicken kann. Ich habs dann sein gelassen und mich mit meinem Navi befasst, da ist die Doku wesentlich besser.

Das ist genau mein Problem mit ARM, dass es keine einheitliche Plattform gibt oder zumindest sowas in der Art wie ACPI.

Du willst auch auf x86 eigentlich kein ACPI. Was du willst, ist eine vollständige Dokumentation aller Stromsparmechanismen, die es gibt und eine Programmierschnittstelle im Betriebssystem. Was du nicht willst, sind vorgefertigte Routinen in einem abstrakten Bytecode, wo du nicht weißt, was sie tun.

Ist der einzige Unterschied zw. PC und Macintosh nicht, PC noch BIOS und Macintosh nur EFI? Weil dann wäre das für mich eigentlich auch kein Unterschied mehr, jedenfalls nicht mehr lange.

Es gibt Intel-Mainboards für PCs mit EFI. Ansonsten kenne ich die genauen Unterschiede nicht (MacOS läuft nur gepatcht auf normalen PCs, Windows läuft ohne weiteres nicht auf Macs - darum denke ich, dass es eine neue Plattform ist).

Komm mal ins IRC, da diskutiert sich sowas leichter.

[FlashBurn]

Komm mal ins IRC, da diskutiert sich sowas leichter.

Wie, wo?

Du kannst aus jedem Serversystem ein gebrauchbares Desktopsystem machen, indem du eine gute GUI draufbastelst, die mit den drunterliegenden Features umgehen kann.

Das sehe ich anders, ganz speziell wegen dem Scheduler, was für den Server ein guter Scheduler ist, kann für den Desktop scheiße sein (Bsp. cgroups).

Mal reingeschaut? Guck mal, wie lang das Inhaltsverzeichnis ist.

Jap, finde ich jetzt gar nicht so schlecht, so finde ich es schneller.

Du willst auch auf x86 eigentlich kein ACPI. Was du willst, ist eine vollständige Dokumentation aller Stromsparmechanismen, die es gibt und eine Programmierschnittstelle im Betriebssystem. Was du nicht willst, sind vorgefertigte Routinen in einem abstrakten Bytecode, wo du nicht weißt, was sie tun.

Ich will die Geräte und was man noch so alles über den Rechner erfahren kann und sollte.

[erik.vikinger]

Hallo,

.... und zum anderen darf die Summe aller Anforderungen nicht den verfügbaren Speicher (inklusive Swap) überschreiten. Auf einem Embedded-Device ohne Swap heißt das, dass kein Overcommit stattfindet, trotz MAP_LAZY.

Genau da muss ich Dir leider widersprechen, bestimmte Kernel aus der 2.6er-Serie haben das anders tatsächlich gemacht und so in einigen Embedded-Systemen für viel Aufregung gesorgt weil sie eben ohne konkrete Fehlermeldung in panic gegangen sind.

Der OOM-Killer kommt also nur unter Speicherlast, ausgereiztem Swapspace und genau dann, wenn der Kernel selbst Speicher braucht.

Soweit die Theorie. Wenn das in der realen Praxis auch so funktioniert bin ich (und die Programme die ich benutze) zufrieden.

Darum lehne ich Swapping ja auch nicht ab, sondern versuche es nur schlechtzumachen.

Aha, nun dann lasse ich Dir Dein kleines Vergnügen.

Es ist besser als keine Lösung, aber eben niemals eine gute Lösung.

Dem kann ich mich zu 99% anschließen. Es gibt IMHO auch Situationen wo Swapping durchaus eine gute Lösung sein kann, zumindest aus wirtschaftlichen oder einfach nur praktischen Gründen. Ansonsten stimme ich Dir zu.

Außerdem sind die OMAP-Datenblätter das allerletzte.

Hm, das kann ich so nicht nachvollziehen. Ich hab mir mal das von Dir verlinkte Datenblatt zum OMAP4430 angesehen (okay nur grob überflogen aber an ein paar einzelnen Punkten genauer hingesehen) und muss ehrlich sagen das genau sowas mir zum Tegra 2 extrem fehlt. Die 5552 Seiten sind natürlich reichlich fett aber dafür bleibt auch kaum eine Frage offen (jedenfalls die Fragen die ich so typischerweise stelle wenn ich so ein Datenblatt das erste mal überfliege). Das einzigste was ich vermisst habe war eine genaue Pin-Beschreibung und generell die physische Spezifikation (Gehäuse mit Pin-Platzierung, Frequenzen, Spannungen, Ströme usw. eben alles was der Board-Designer wissen will).

Dumm ist halt nur, dass TI wirklich gute Chips herstellt und es kaum Alternativen gibt...

Naja, das hängt wohl auch vom geplanten Anwendungszweck ab, für das was mir so vorschwebt ist der Funk-Teil völlig uninteressant und der Tegra 2 hat dafür einen PCI-Express-Root-Port. Beiden fehlt SATA (etwas das Marvell dafür zu bieten hat) was sich aber am Tegra 2 eigentlich per PCI-Express brauchbar nachrüsten lässt (warum das in dem TrimSlice per USB gemacht wird verstehe ich auch nicht). Deswegen würde ich mir gerne auf Basis des TrimSlice ein eigenes Tegra 2 Board basteln mit einer PCI-Express-Bridge an der dann zweimal GBit-LAN von Intel und einmal SATA (wohl von JMicron) hängen soll, nur dürfte das kaum realisierbar sein weil NVidia eben keine gescheiten Datenblätter raus rückt.


Grüße
Erik

[FlashBurn]

Deswegen würde ich mir gerne auf Basis des TrimSlice ein eigenes Tegra 2 Board basteln mit einer PCI-Express-Bridge an der dann zweimal GBit-LAN von Intel und einmal SATA (wohl von JMicron) hängen soll, nur dürfte das kaum realisierbar sein weil NVidia eben keine gescheiten Datenblätter raus rückt.

Ich weiß vom AC100 das zwar ein PCIE Header vorhanden ist, aber trotzdem nur per USB2 verbunden wird (frag mich ja nicht nach den Einzelheiten, ich habe es soweit verstanden, das man halt physikalisch nen PCIE Slot hat, aber angebunden ist das ganze dann per USB2). Problem beim Tegra ist halt, die Multimediasachen sind nicht so toll wie immer dargestellt wird und von der USB-Performance möchte ich gar nicht erst anfangen. Allerdings möchte ich meinen das die bei den OMAPs auch nicht besser sein soll.

[Svenska]

.... und zum anderen darf die Summe aller Anforderungen nicht den verfügbaren Speicher (inklusive Swap) überschreiten. Auf einem Embedded-Device ohne Swap heißt das, dass kein Overcommit stattfindet, trotz MAP_LAZY.

Genau da muss ich Dir leider widersprechen, bestimmte Kernel aus der 2.6er-Serie haben das anders tatsächlich gemacht und so in einigen Embedded-Systemen für viel Aufregung gesorgt weil sie eben ohne konkrete Fehlermeldung in panic gegangen sind.

Das würde ich dann aber als Bug bezeichnen, nicht als Feature.

Ich hab mir mal das von Dir verlinkte Datenblatt zum OMAP4430 angesehen (okay nur grob überflogen aber an ein paar einzelnen Punkten genauer hingesehen) und muss ehrlich sagen das genau sowas mir zum Tegra 2 extrem fehlt.

Die Dokumentationen von Nvidia kenne ich nicht, aber das Datenblatt von Samsung (z.B. hier) finde ich wesentlich angenehmer zu lesen. In den knapp 600 Seiten dort ist auch der unterstützte ARM-Befehlssatz enthalten und das Dokument wirkt wesentlich weniger aufgebläht.

Vielleicht bin ich auch anders als andere Menschen, aber ich versuche ein System erstmal grob zu verstehen, bevor ich ins Detail gehe und TIs Datenblatt macht einen Überblick für mich nahezu unmöglich. Allein die 170 Seiten Inhaltsverzeichnis machen ohne Suchfunktion keinen Spaß (und man muss genau wissen, wonach man sucht und wie es im Datenblatt genannt wird).

Andererseits ist der OMAP ein ordentliches Stück komplexer als der S3C, aber fast 5000 zusätzliche Seiten braucht man dafür nicht.

Deswegen würde ich mir gerne auf Basis des TrimSlice ein eigenes Tegra 2 Board basteln

Selber basteln ist für mich bei den Geschwindigkeiten eher zu schwierig, das lass ich lieber sein. Obwohl mich das auch mal reizen würde, aber das ist am Ende eh nur eine Zeitsenke und landet irgendwann in der Ecke.

Gruß,
Svenska