Lowlevel
Lowlevel => OS-Design => Thema gestartet von: FlashBurn am 21. August 2011, 22:00
-
Mir geht es bei diesem Thema eigentlich um eine ganz einfache Frage, wie oft kommt es vor das man wirklich mehrere/viele physikalische Pages, die nicht zusammenhängend sind, mappen will?
Ich frage deswegen, weil ich gerade (oder besser immernoch :( ) dabei bin meinen Kernel nach C++ zu portieren und dabei auch gleich mal nen kleineren rewrite starte.
Gerade bin ich halt dabei den VMM zu portieren und da ist mir halt der Gedanke gekommen, das es (zumindest bei mir) sehr von Vorteil wäre, wenn man mit einem Funktionsaufruf mehrere Pages mappen könnte (ich kann das jetzt auch schon, allerdings nur zusammenhängende Pages). Aber da stellt sich mir dann die Frage ob man das eigentlich wirklich braucht? Denn wenn ich die Funktion darauf optimieren würde, das nur eine Page gemappt wird, kann sie auch ein Stückchen schneller werden und meiner Meinung nach ist das auch fast immer der Fall (außer beim Booten des Kernels) und würde so mehr Sinn machen und wenn man dann doch mal mehrere Pages mappen will, muss halt die Funktion mehrmals aufgerufen werden.
-
Für normale Speicherallokationen ist es völlig egal, wie das Layout physisch aussieht. Eine Funktion, die Pages virtuell zusammenhängend, aber physisch einfach irgendwie verstreut alloziert, ist also für den Großteil genau das, was du willst. Treiber können unter Umständen auch mal mehr physisch am Stück wollen, wenn es dein PMM also hergibt, kann es nicht schaden, das auch anzubieten.
-
Mir geht es nicht um das allozieren (das ist bei meinem PMM auf eine Page beschränkt), sondern um das Mappen, sprich das Eintragen in die PageTables (und alles was damit verbunden ist).
Ich würde die gerne auf den Average-Case optimieren und das sollten ja eigentlich einzelne Pages sein. Daher meine Frage wo man (außer bei Treibern, was ja eigentlich auch nur einmal passiert) mehrere Pages mit einmal mappen möchte.
Ansonsten wird ja, wenn ein Programm nach mehr Speicher fragt, dieser nicht sofort gemappt, sondern der wird ja Page für Page durch den Zugriff darauf gemappt (Paging-Exception).
Auf der einen Seite könnte ich mir die Schleife(n) sparen, was somit das Mappen einzelner Pages schneller macht und dafür wäre dann das Mappen mehrerer Pages eher langsam, weil dann die ganzen Überprüfungen die die Mapping Funktion so macht, dann für jede Page immer wieder gemacht werden und auch zwecks Locking ist das dann eher schlecht (was aber nicht so schlimm wäre, wenn sowas nicht alzu oft bis eher selten vorkommt).
Optimiere ich allerdings auf das Mappen mehrerer Pages auf einmal, dann würde dieser Vorgang sehr beschleunigt werden und vorallem wäre dann, bei meiner momentanen Idee, der Fehlerfall und das Aufräumen auch verdammt schnell.
-
Wenn du eine Funktion, die mehrere Seiten mappen kann, nur für eine einzelne Seite nutzt, ist der Overhead doch der Code, der für for (int i = 0; i < n; i++) mit n = 1 ausgeführt wird, oder?
-
Ein wenig mehr ist es noch, weil die Funktion bei Fehlern auch noch ein wenig Aufräumarbeit macht (da muss dann ein wenig gerechnet werden und wieder ne Schleife durchgegangen werden), aber ich werde einfach meine Idee von gestern Abend noch umsetzen. Denn dadurch wird die Arbeit der Funktion noch weniger (auch für mehrere Pages).
Wenn ihr auch mehrere Pages (die nicht zusammenhängend sind) mappen könnt. Wie übergebt ihr die der Funktion?
-
Fehler sollten aber normalerweise nicht auftreten, also sollte der Vorgang für n=1 kaum Overhead produzieren. :evil:
Entwickle ein virtuelles Dateisystem (ähnlich /sys/) und zähle einfach mit, wie oft welche Größen gemappt werden. Dann weißt du, was das Optimierziel ist. ;-)
Die meiste größere Software (Firefox, Openoffice, ...) alloziiert relativ viel Speicher und nutzt den dann auch. Für jede einzelne Page die Exception abzuwarten und erst dann zu mappen wird in dem Fall teuer; schneller wäre es dann, wenn du bereits beim malloc() mappst (abhängig von irgendwelchen Kriterien).
Gruß,
Svenska
-
Wenn ihr auch mehrere Pages (die nicht zusammenhängend sind) mappen könnt. Wie übergebt ihr die der Funktion?
tyndur mappt normal nur in Tateinheit mit Allokation, das macht die Interfaces gleich etwas einfacher. ;)
Redest du jetzt von physisch nicht zusammenhängend oder virtuell nicht zusammenhängend? Ich finde deinen Eingangsbeitrag sehr verwirrend, was das angeht. Du redest zwar von physischem Speicher, aber meinst das Mapping. Irgendwas passt da für mich nicht zusammen.
-
Hallo,
zum einen bin ich ebenfalls der Meinung das eine simple Schleife kein so großer Overhead ist (hier muss ich Svenska ausnahmsweise mal zustimmen ;)) und zum anderen bin auch der Meinung das MAP_NOW für die meisten Fälle die bessere Variante ist (zu diesem Thema hatte wir doch schon mal diskutiert) so das die meisten Aufrufe wohl doch mehrere Pages mappen wollen. Es gibt sicher etliche Situationen wo MAP_LAZY Vorteile bringen kann aber das ist IMHO nicht die Regel.
Grüße
Erik
PS.: "Tateinheit" klingt gut, ist hier aber auch wirklich zu treffend ;)
-
Redest du jetzt von physisch nicht zusammenhängend oder virtuell nicht zusammenhängend? Ich finde deinen Eingangsbeitrag sehr verwirrend, was das angeht. Du redest zwar von physischem Speicher, aber meinst das Mapping. Irgendwas passt da für mich nicht zusammen.
Autor: Svenska
Ich rede von virtuell zusammenhängend, aber nicht physisch zusammenhängend. Bisher kann ich entweder eine Page oder viele physisch zusammenhängende Pages mappen (physische Pages in den virtuellen Adressraum mappen).
Fehler sollten aber normalerweise nicht auftreten
Eigentlich nicht, aber da meine momentane Variante auch noch die PageTables mappt (und dafür eine Page braucht, was ja fehlschlagen könnte) und ich halt darauf überprüfe ob versucht wird, auf eine schon vorhandene Page zu mappen, kann es halt doch zu Fehlern kommen.
Ich habe bei meinem PMM (der auf Bitmaps basierte) auch immer überprüft ob die Page wirklich benutzt ist, bevor ich sie freigegeben habe und ich überprüfe auch immer das alles was auf Pages arbeitet, mir auch wirklich eine Pageadresse gegeben hat. Sollte/kann ich denn sowas weglassen?
Ich dachte eigentlich das Linux und Windows dieses MAP_LAZY machen?!
Auf eine Frage habt ihr aber noch nicht geantwortet, wie bekommt ihr mehrere Pages an die Mapping-Funktion übergeben? Ich habe ja kein malloc() und einfach mal ein statisches Array auf dem Stack kann ich auch nicht erzeugen (jedenfalls nicht zu groß), da ich im Kernel nur 4kb Stack habe.
Ich will das dann so machen, das der VMM immer schon die physischen Pages in den PageTables reinschreibt (und somit auch für das PageTable Mapping verantwortlich ist) und die Mapping-Funktion dann nur noch die Flags setzen muss und die entsprechenden TLB Einträge ungültig macht.
tyndur mappt normal nur in Tateinheit mit Allokation, das macht die Interfaces gleich etwas einfacher.
Irgendwie steh ich hier aufm Schlauch :-(
-
Ich dachte eigentlich das Linux und Windows dieses MAP_LAZY machen?!
Zumindest für Linux stimmt das (bzw. bei einem anonymen Mapping wird erstmal eine Page voll Nullen mit COW gemappt, glaube ich).
tyndur mappt normal nur in Tateinheit mit Allokation, das macht die Interfaces gleich etwas einfacher.
Irgendwie steh ich hier aufm Schlauch :-(
vaddr_t mmc_valloc(mmc_context_t* context, size_t num_pages, int flags);
Das Ding sucht sich einen virtuell zusammenhängenden Speicherbereich für num_pages Seiten raus und macht dann für jede einzelne Seite ein pmm_alloc(1), so dass die physische Anordnung egal ist. Es wird direkt gemappt, so dass auch kein zusätzliches Array oder irgendwas nötig ist.
-
Lazy mapping ist dann von Vorteil, wenn eine Anwendung erstmal präventiv Speicher reserviert, ihn aber erst später auch wirklich nutzt. Der Vorteil ist, dass die Anwendung schnell bereit ist und auf den Benutzer reagieren kann.
Sofortiges Mapping ist sinnvoll, wenn eine Anwendung den angeforderten Speicher sofort nutzt und führt zu einem sofort höheren Speicherbedarf, was wiederum das Speichermanagement unter Druck setzen kann (bisher nicht genutzter Speicher muss bei Knappheit nicht ausgelagert werden, wenn er aber gemappt ist, muss man ihn als benutzt ansehen). Außerdem ist es einfacher zu debuggen. ;-)
Optimal ist vermutlich eine Mischung aus beiden Systemen, wobei man die Randbedingungen sinnvoll wählen muss. Da hab ich aber keine gute Idee...
Zum Thema: Die meisten Allokationen, die durch den VMM müssen, sind größer als eine Page. Von daher sollte ein virtuell zusammenhängender Adressraum in einem Rutsch gemappt werden können. Wenn man das durch einzelne Syscalls machen muss, hat man bei mehreren Threads in einem Prozess, die gleichzeitig ein malloc() aufrufen, ein Problem.
Gruß,
Svenska
-
Das Ding sucht sich einen virtuell zusammenhängenden Speicherbereich für num_pages Seiten raus und macht dann für jede einzelne Seite ein pmm_alloc(1), so dass die physische Anordnung egal ist. Es wird direkt gemappt, so dass auch kein zusätzliches Array oder irgendwas nötig ist.
Das würde bei mir nicht klappen, weil ich mir dann doch noch eine extra Mapping-Funktion schreiben müsste. Zumal bei mir noch dazu kommt, das ich zw. Ein-CPU- und Mehr-CPU-System unterscheide und das zwei unterschiedliche Funktionen sind (vom Code her).
Ich habe das alles schön voneinander getrennt.
Die meisten Allokationen, die durch den VMM müssen, sind größer als eine Page.
Richtig, allerdings bin ich ja von MAP_LAZY ausgegangen.
Von daher sollte ein virtuell zusammenhängender Adressraum in einem Rutsch gemappt werden können. Wenn man das durch einzelne Syscalls machen muss, hat man bei mehreren Threads in einem Prozess, die gleichzeitig ein malloc() aufrufen, ein Problem.
Da hast du das dann nicht richtig verstanden. Speicher per Syscall anfordern und den Speicher mappen sind in dem Sinne voneinander getrennt.
Das Programm macht nen Syscall des es Speicher haben will (Vmm::allocUser()), diese Funktion versucht dann einen Bereich aus dem virtuellen Adressraum zu bekommen (VmmAddrSpace::m_Vmm.alloc()) und wenn das geklappt hat, wird in einer Schleife, immer eine Page vom PMM geholt (Pmm::alloc4kb()) und gemappt (Vmm::mapUser()).
Von daher hat das eine (Mappen einer oder mehrerer Pages), in dem Sinne, nichts mit dem anderen (allozieren von Speicher) zu tun.
Optimal ist vermutlich eine Mischung aus beiden Systemen, wobei man die Randbedingungen sinnvoll wählen muss. Da hab ich aber keine gute Idee...
Das ist aber schade.
Sollte man das komplett dem Programm überlassen? Ich würde dann nur den Stack per MAP_LAZY mappen und alle Allozierungen muss dann das Programm wissen ob es MAP_LAZY haben will oder nicht.
-
Hallo,
Das würde bei mir nicht klappen, weil ich mir dann doch noch eine extra Mapping-Funktion schreiben müsste.
Dann lagere das Mapping doch in eine kleine Extra-Funktion aus. So hast Du nur einmal diesen Code und dem Compiler steht es immer noch frei das zu inlinen (was er bei statischen und kleinen Funktionen auch gerne tut und wenn er das nicht tut dann hat er seine Gründe).
allerdings bin ich ja von MAP_LAZY ausgegangen.
Das bringt zwar manchmal was aber IMHO nur selten. Ich persönlich bin der Meinung das die Programme die wissen das sie den Speicher nur vorsorglich allozieren das dem OS auch passend mitteilen sollten und für den Rest ist, so denke ich, MAP_MAY_NOW die beste Default-Option.
Für Dinge wie den Stack ist das sicher anders aber die Mehrheit der malloc-Aufrufe dürfte dem Zweck dienen den Speicher auch zeitnah zu nutzen.
Beim MAP_LAZY sehe ich aber noch ein kleines Problem: das OS sollte wissen wie vielen Speicher es den Anwendungen insgesamt zugesichert hat und sicherstellen das dann später auch tatsächlich mit physischen Speicher hinterlegt werden kann. Das ist nicht schwer aber man muss es berücksichtigen. Es wäre mMn recht unhöflich wenn der malloc-Syscall erfolg meldet aber das Programm dann trotzdem wegen Out-of-Memory gekillt wird (ja ich weiß dass das mit dem OOM-Killer trotzdem noch passieren kann aber der sollte IMHO nur der letzte Notnagel sein, im regulären Betrieb ohne SW-Amokläufe sollte es keine OOM-Signale geben sondern nur negative Rückgabewerte beim malloc-Syscall).
Grüße
Erik
-
Overcommit wird im allgemeinen als Feature angesehen, nicht als Bug. Soweit ich weiß, kann man Linux entsprechend konfigurieren, dass es nicht mehr overcommittet, dann kommt auch kein OOM-Killer mehr zum Zug, sondern es kann höchstens mal eine Allokation schiefgehen. Dafür verschenkst du halt ungenutzten Speicher.
-
Dann lagere das Mapping doch in eine kleine Extra-Funktion aus. So hast Du nur einmal diesen Code und dem Compiler steht es immer noch frei das zu inlinen (was er bei statischen und kleinen Funktionen auch gerne tut und wenn er das nicht tut dann hat er seine Gründe).
Ist genau das was ich mache, ich wollte eigentlich nur sagen, das es bei meinem Design (hat vorallem viel mit dem Init des Kernels zu tun) nicht geht. Auch inlinen geht nicht, da der Compiler nicht wissen kann welche Funktion (ob Ein- oder Mehr-CPU-System) zur Laufzeit genutzt wird (es wird trotzdem kein indirekter-Call gemacht).
@taljeth
Wie mappt ihr dann Speicher für Geräte? Da musst du doch den Speicher an die Mapping-Funktion übergeben und kannst das nicht den PMM erledigen lassen? Sag nur dafür habt ihr extra eine Funktion (was ja dann doppelter Code wäre)?
@all
Was den OOM-Killer betrifft, wie will man den eigentlich vernünftig implementieren?
Zumal theoretisch ja alleine schon durch Swapping eine 4kb Page ausreichen sollte damit jeder Prozess seinen gesamten Adressraum nutzen kann, dass das nicht praxistauglich ist, ist mir klar.
-
Soll ich dir ein Geheimnis verraten? Funkionen können sich gegenseitig aufrufen. ;)
mmc_valloc() ruft intern natürlich mmc_map() auf, um die einzelnen Pages zu mappen, und das kann man über einen anderen Syscall auch direkter erreichen. Aber in diesem Pfad wird halt kein physischer Speicher alloziert, sondern einfach nur ein bestimmte Adresse gemappt.
OOM-Killer und vernünftige Implementierung widerspricht sich. Der OOM-Killer ist ein Hack, um eine aussichtslose Situation noch halbwegs zu retten.
-
mmc_valloc() ruft intern natürlich mmc_map() auf, um die einzelnen Pages zu mappen
Ich denke sowas gibt es by tyndur nicht? (ein paar Posts weiter zurück, hattest du doch geschrieben, das ihr direkt mappt, ohne eine Funktion dazwischen, der die Page übergeben wird)
Sprich ihr habt das genauso wie ich bisher, aber macht ihr keine Überprüfungen ob die Parameter die der Funktion übergeben werden, in Ordnung sind? Und ruft ihr dann für den Speicher für die Geräte auch immer für jede Page diue Funktion auf?
Der OOM-Killer ist ein Hack, um eine aussichtslose Situation noch halbwegs zu retten.
Das wiederspricht sich für mich auch. 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.
-
mmc_map() mappt genau einen virtuell zusammenhängenden Bereich auf genau einen physisch zusammenhängenden Bereich, braucht also auch keine aufwendigen Datenstrukturen oder Arrays als Parameter. Das reicht, um ein mmc_valloc() zu implementieren, das einen virtuell zusammenhängenden Bereich alloziert und physisch (nicht zusammenhängend) irgendwohin mappt.
Und wenn du keinen OOM-Killer willst, darfst du halt nicht overcommitten.
-
Wäre wahrscheinlich ein extra Thread, aber wie sehr vertraut ihr eurem eigenen Code? Ich meine damit, ob ihr bei "inneren" Funktionen (z.B. die Mapping-Funktion, die eigentlich nicht von außen, sondern nur aus dem Kernel, mit Parametern die direkt vom PMM kommen, aufgerufen werden) trotzdem bestimmte Sicherheitschecks macht?
Ich überprüfe z.B. beim PMM ob die Page die freigegeben werden soll, auch wirklich ne Page ist (das mache ich auch bei anderen Funktionen, wie nem vfree()). Selbst bei "inneren" Funktionen.
-
Hallo,
Overcommit wird im allgemeinen als Feature angesehen, nicht als Bug.
Da bin ich ja froh das ich nicht allgemein bin. ;)
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.
aber wie sehr vertraut ihr eurem eigenen Code?
Nicht allzu sehr, ich habe normalerweise am Anfang jeder Funktion ein paar Plausibilitätsprüfungen drin, nur das die bei inneren Funktionen oft zwischen #if DEBUG und #endif stehen.
Grüße
Erik
-
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
-
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.
-
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.
-
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
-
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).
-
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.
-
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.
-
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
-
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?
-
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 (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
-
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.
-
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
-
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:
(http://ck.kolivas.org/patches/bfs/supported_features.png)
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.
-
Linux ist für den Desktop genauso gut geeignet wie Windows für den Server, schließlich wird letzteres dafür ja teuer verkauft. :roll:
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) (http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip) oder sowas (OMAP4430) (http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vW.zip).
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. ;-)
-
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.
-
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. ;-)
-
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.
-
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
-
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.
-
.... 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 (http://www.wvshare.com/datasheet/SAMSUNG_PDF/S3C2410.PDF)) 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
-
@offtopic
Ich habe mir jetzt mal Boards mit diesem Samsung SoC angeguckt und eigentlich sind die interessant, aber die CPU wäre mir halt zu alt und was ich nicht verstehe, warum sind die so teuer? Ich meine ich hatte ein Board dabei, dafür bekommt man schon nen Fertig-PC (und der hat wesentlich mehr Leistung und Hard- und Software dabei). Liegt das daran, dass diese Boards nicht in solch großen Stückzahlen hergestellt werden? Eigentlich heißt es doch immer das ARM so günstig ist.
-
Ich zerlöte doch kein neues Navigationsgerät. :-) Das Ding ist hinreichend alt, für die Originalsoftware gibt es seit einigen Jahren keine Karten mehr und neue Software läuft ziemlich schleppend. Das Mini2440 (400 MHz, 64 MB RAM, 256 MB NAND, 2 MB NOR) kostet bei Watterott (inkl. 3.5" Display) etwas über 100 €, wenn man bei arm9.net bestellt 74 € plus Importkosten.
Die Dinger werden viel billiger, wenn man sie im Zehntausenderpack kauft... und für teure Einzelstücke ist der Markt anscheinend vorhanden, außerdem ist "spart Strom" ein Killerargument gegen x86 und damit lassen sich die hohen Preise gut rechtfertigen. Marktwirtschaft halt. :-P
Gruß,
Svenska
-
Hallo,
Das würde ich dann aber als Bug bezeichnen, nicht als Feature.
Endlich sind wir mal einer Meinung. :)
Trotzdem ist das wohl vorgekommen, hat mir zumindest jemand erzählt der mit Linux in kleinen Embedded-Schachteln deutlich mehr macht als ich.
Die Dokumentationen von Nvidia kenne ich nicht,
Kein Wunder, das ist leider nicht öffentlich verfügbar, nicht mal als registrierter Developer bekommt man das.
aber das Datenblatt von Samsung (z.B. hier (http://www.wvshare.com/datasheet/SAMSUNG_PDF/S3C2410.PDF)) 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.
Das ist ja auch "nur" ein kleiner Mikrocontroller (obwohl ich den "DC Input (Latch-up) Current" mit 200mA recht bemerkenswert empfinde, üblich sind da eher so 20mA). Da ist zwar ein kleiner LCD-Controller aber kein 3D-Graphik-Controller (mit aufwändigem Frame-Buffer im DRAM usw.), kein Kamera-Controller, kein GSM/UMTS-Controller, kein PCI-Express, kein USB 2, kein .... drin. Zwischen dem S3C2410 und einem OMAP4 oder Tegra 2 liegen Welten und wohl mehr als 5000 Seiten Dokumentation.
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).
Sowohl der Akrobat-Reader als auch Okular zeigen das auch als Baumstruktur an mit der man mMn recht angenehm arbeiten kann um zumindest einen guten Überblick zu bekommen. Aber der Umgang mit Dokumenten in der Größenordnung ist wohl auch etwas Übungssache.
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.
Das meiste anspruchsvolle sind serielle differentielle Verbindungen für die man im wesentlichen 2 Leitungen parallel und mit gleicher Länge möglichst ohne Störungen verlegen muss aber gerade simpel ist das nun wahrlich nicht. ;)
Aber wenn man nicht konkret weiß was das Ziel sein soll dürfte die Einschätzung mit der Zeitsenke recht treffend sein. Bleibt übrig dass das weder mit dem OMAP 4 noch mit dem Tegra 2 Sinn ergibt da dem einem eben PCI-Express fehlt um beliebige Peripherie nachzurüsten und dem anderen jegliche Informationen um überhaupt anfangen zu können. :(
warum sind die so teuer?
Development-Boards sind immer etwas teuer. Zum einen bekommt man da oft auch noch interessante Datenblätter, und Schaltpläne und manchmal sogar das komplette Platinenlayout dazu. Zum anderen verkauft sich sowas nicht gerade in großen Stückzahlen.
Für mein Ziel hab ich mir auch schon ernsthaft überlegt das Q7-NT2 (http://www.msc-ge.com/en/produkte/com/moduls/overview/6100-www.html) zu kaufen und nur ein Base-Board dazu zu basteln aber es sind leider trotzdem nur 1 GB RAM drauf, dafür ist schon eine PCI-Express-Bridge (der IDT-Chip oben links) mit 3 frei verfügbaren x1-Gen1-Lanes und einmal GBit-LAN (der Intel-Chip unten links) drauf und an der Q7-Verbindung verfügbar so dass das Base-Board nur noch einen zweiten GBit-LAN-Controller bäuchte und der Vollständigkeit halber einen xHCI-USB-Controller (wie den TUSB7340 (http://focus.ti.com/docs/prod/folders/print/tusb7340.html) von TI).
Grüße
Erik
-
Hallo,
Das ist ja auch "nur" ein kleiner Mikrocontroller (obwohl ich den "DC Input (Latch-up) Current" mit 200mA recht bemerkenswert empfinde, üblich sind da eher so 20mA). Da ist zwar ein kleiner LCD-Controller aber kein 3D-Graphik-Controller (mit aufwändigem Frame-Buffer im DRAM usw.), kein Kamera-Controller, kein GSM/UMTS-Controller, kein PCI-Express, kein USB 2, kein .... drin. Zwischen dem S3C2410 und einem OMAP4 oder Tegra 2 liegen Welten und wohl mehr als 5000 Seiten Dokumentation.
Naja, der 3D-Teil ist bei TI ebenfalls nicht hinreichend dokumentiert (halt ein PowerVR-Chipsatz). Der Kameracontroller belegt im Datenblatt für den S3C2440 (Nachfolger bis 400 MHz) 28 Seiten. GSM/UMTS-Modems sind normalerweise serielle Standardbauteile, die man nicht kilometerlang dokumentieren muss (vielleicht 50 Seiten) und der Chip kann USB 1.1 Host wie Gast. Dass er kein USB 2.0 kann, liegt wahrscheinlich daran, dass es ihn schon seit über acht Jahren gibt. ;-)
Ich bleibe bei meiner Einschätzung, dass das Datenblatt nicht über 2000 Seiten hätte haben müssen. Das kann man nicht mehr lesen, sondern nur noch punktweise überfliegen.
Sowohl der Akrobat-Reader als auch Okular zeigen das auch als Baumstruktur an mit der man mMn recht angenehm arbeiten kann um zumindest einen guten Überblick zu bekommen. Aber der Umgang mit Dokumenten in der Größenordnung ist wohl auch etwas Übungssache.
Im Inhaltsverzeichnis sehe ich, was drin ist. Nicht, wie es funktioniert. Aber vielleicht kann einfach kaum jemand vernünftige Datenblätter schreiben oder meine Anforderungen sind seltsam.
Oberklasse-Chips sind halt teurer als das, was man auf Messen hinterhergeworfen kriegt (mal ein STM8, mal ein STM32, dann wieder ein LPC irgendwas... halt so Zeug mit Flash und RAM im KB-Bereich). Und wenn sich 20 Hersteller darum streiten, wer den besseren Cortex-A9 synthetisiert kriegt, ist der Markt plötzlich wieder sehr, sehr klein. Leider.
Gruß,
Svenska