1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Canonical: "Warum wir Mir…

"serversetige Speicherverwaltung"

  1. Thema

Neues Thema Ansicht wechseln


  1. "serversetige Speicherverwaltung"

    Autor: /mecki78 11.03.13 - 15:33

    Warum will man für ARM serverseitige Speicherverwaltung? Serverseitige Speicherverwaltung bringt zwar keine Nachteile, wenn Client und Server auf der gleichen Maschine laufen, ich sehe aber auch nicht, dass es groß Vorteile bringt. Und wenn sie auf unterschiedlichen Maschinen laufen, dann bringt es sogar IMHO nur Nachteile. Und ich sehe gleich doppelt nicht, was das mit ARM zu tun haben soll. ARM ist nur eine CPU mit anderen Instruktionen als x86 oder PPC und ansonsten verhält sie sich was Speicherzugriffe angeht irgendwo zwischen x86 und PPC, aber nicht grundlegend anders als diese beiden CPU Typen.

    Ich meine, dieser Punkt scheint ja Canonical sehr wichtig zu sein, wenn sie ihn extra so hervorheben. Die Wayland Entwickler haben sich für clientseitige Verwaltung entschieden, was aus meiner Sicht durchaus Sinn macht, denn die UI Systeme von Windows oder OS X machen das auch so und gewisse Grafikeffekte könnten nie die heutige Performance erzielen, würde man das nicht so machen.

    /Mecki

  2. Re: "serversetige Speicherverwaltung"

    Autor: felix.schwarz 11.03.13 - 16:33

    "ARM" an sich ist nicht das Problem, sondern gängige ARM-Plattformen, also insbesondere Mobilegeräte/Tablets. Dort sind die Hardware-Ressourcen so limitiert, dass man server-seitige Speicherverwaltung benötigt.

    Einige Details lassen sich im bekannten "first contact" Wayland-Chatprotokoll nachlesen.

  3. Re: "serversetige Speicherverwaltung"

    Autor: shoggothe 11.03.13 - 16:54

    Clients und Server laufen auf der selben Maschine. Es ist ein Windowing-System wo sich viele Clients (die Anwendungsprozesse) mit einem zentralen Window-Server (auch ein oder mehrere Prozesse) unterhalten.

    Canonical möchte serverseitige Speicherverwaltung, weil das unter Android so umgesetzt ist. Sie möchten die nicht im Quelltext vorliegenen Treiber für ARM-Hardware anbinden.

    Die Wayland-Entwickler haben sich keinesfalls auf eine clientseitige Speicherverwaltung festgelegt. Die Referenzimplementierung ist so umgesetzt, aber die Wayland-APIs schreiben in der Richtung nichts vor.

    Canonical hat also (irrtümlich) geglaubt, dass sie mit Wayland ihre Anforderungen nicht umsetzen können. Aber anstatt sich genauer zu informieren oder sogar aktiv am Wayland-Projekt in ihre Richtung mit zu wirken, haben sie sich dafür entschieden, heimlich still und leise was Eigenes zu köcheln. Canonical halt.

  4. Re: "serversetige Speicherverwaltung"

    Autor: lear 11.03.13 - 22:14

    Vergiß es. Entweder sie haben bislang keinen Code geschrieben oder sind noch zu inkompetent zu merken, welche Probleme sie sich da einhandeln (sie werden ja schlecht beliebige clients in serverspeicherbereiche schreiben lassen können; shm ist ein ähnliches sicherheits- und bluescreenproblem; nachgelagerte speicherverwaltung möglich, aber das gegenteil von schnell und ich bezweifele, daß canonical jemand mit der erforderlichen kompetenz beschäftigt - und wenn sie dann ein protokoll für upload und sync einsetzen, haben sie gerade den roundtrip erfunden)

    Wenn man weiß, warum der Speicher in X11 vom Server alloziert wird und unter welchen Voraussetzungen das eingeführt wurde, möchte man sich an den Kopf fassen.

    Auf einem system wie Android, wo derartige Speicherreallokation eher selten vorkommt ist das kein großes Problem, aber für den "Desktop", wo Fenster auftauchen, verschwinden und dauern ihre Größe ändern ist das wengier optimal (wobei ich mir nicht mal sicher bin, ob android das speziell macht oder nur allgemein den speicher pro äpp limitiert)
    Kann natürlich sein, daß es ohnehin nur noch in die Richtung geht oder daß sie den Kernel in Mir reinforken...

    Pack noch das Gerangel um den input stack ("weil wayland zu unsicher ist" -> "weil wayland noch keinen hatte", was bedeutet, daß sie mit Mir 6 Monate vor dem ersten bazaar commit angefangen haben...) - es ist nur noch traurig.

    Als Canonical sich darauf konzentriert hat, leute mit ihrer simplen "hier, schaut mal - besser als windows?" Vorauswahl anzusprechen, waren sie wirklich ein Gewinn, aber seitdem hat sich leider viel geändert :-(

  5. Re: "serversetige Speicherverwaltung"

    Autor: /mecki78 12.03.13 - 11:55

    felix.schwarz schrieb:
    --------------------------------------------------------------------------------
    > "ARM" an sich ist nicht das Problem, sondern gängige ARM-Plattformen, also
    > insbesondere Mobilegeräte/Tablets. Dort sind die Hardware-Ressourcen so
    > limitiert, dass man server-seitige Speicherverwaltung benötigt.

    Bei Windows ist die Speicherverwaltung auch clientseitig und Windows 8 läuft doch auf Tablets und sogar noch limitierteren Smartphones. Also warum funktioniert das (mal wieder) unter Windows, ist aber unter Linux angeblich ein Problem? Das kann ich irgendwie nicht nachvollziehen. Abgesehen davon das heutige Mobilgeräte "mehr Resourcen" haben als Desktoprechner noch vor 10 Jahren und bereits vor 10 Jahren war die Speichervelwaltung unter Windows und OS X clientseitig.

    /Mecki

  6. Re: "serversetige Speicherverwaltung"

    Autor: nille02 12.03.13 - 13:59

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > felix.schwarz schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > "ARM" an sich ist nicht das Problem, sondern gängige ARM-Plattformen,
    > also
    > > insbesondere Mobilegeräte/Tablets. Dort sind die Hardware-Ressourcen so
    > > limitiert, dass man server-seitige Speicherverwaltung benötigt.
    >
    > Bei Windows ist die Speicherverwaltung auch clientseitig und Windows 8
    > läuft doch auf Tablets und sogar noch limitierteren Smartphones. Also warum
    > funktioniert das (mal wieder) unter Windows, ist aber unter Linux angeblich
    > ein Problem? Das kann ich irgendwie nicht nachvollziehen. Abgesehen davon
    > das heutige Mobilgeräte "mehr Resourcen" haben als Desktoprechner noch vor
    > 10 Jahren und bereits vor 10 Jahren war die Speichervelwaltung unter
    > Windows und OS X clientseitig.

    Ich habe noch ein Windows Phone 8 gesehen das auf einem 100¤ Handy läuft. Die SoCs sind alle erheblich Potenter.

  7. Re: "serversetige Speicherverwaltung"

    Autor: teleborian 12.03.13 - 17:41

    Könnte das mit dem Serverseitig vielleicht mit dem Desktop mode zu tun haben, den sie im Phone mit ihrer Dokingstation anbieten wollen?

  8. Re: "serversetige Speicherverwaltung"

    Autor: lear 12.03.13 - 19:47

    Unwahrscheinlich.

    Je "entfernter" Client und Server wären (so sie denn da irgend eine andere HW per was auch immer außer infiniband angeschlossen haben und nicht einfach den IGP nach draußen schleifen) desto unangenehmer wird die Serverseitige Speicherallokation (performancetechnisch, für den "klassischen" Desktop)
    Hier geht's nur darum, wer den Speicher ggü. dem kernel festhält - nicht "wo".

    Lt. Daniel Stone hat Serverseitige Allokation den Vorteil, daß Du für Vollbildfenster (also auf dem Desktop zB. Spiele, aber nicht einfach ein maximiertes Fenster) den Clientbuffer direkt mit dem Scanout flippen kannst (dafür muß der Speicherbereich kontinuierlich sein) nur leuchtet mir im Moment nicht ein, warum der Client keinen kontinuierlichen Speicherbereich anfordern können und im Erfolgsfall dementsprechend ggü. dem Server taggen sollte (ggü. dem Kernel sollte der Compositor hinsichtlich der Speicherzuweisung erstmal keinerlei Privilegien genießen, ließe sich aber natürlich machen, wenn es denn was hülfe - *dann* wäre natürlich Serverseitige Allokation in der Hinsicht natürlich explizit im Vorteil, betrifft nur den Desktop -fast- nicht, zumal -unfragmentierter- Speicher da jetzt nicht sooo die Mangelware ist wie auf den SOCs)

    Das kann mit der speziellen Androidarchitektur zusammenhängen (obwohl sie ja nur den inputstack verwenden wollen), aber wenn ich da jetzt frei ins Grüne hineindesignen sollte, würde ich das mit der Serverseitigen Allokation schön lassen.
    Es macht wesentlich mehr Ärger als Nutzen.

    X11 alloziert auf dem Server weil SGI damals mit mehreren Prozessoren (also auch Prozessen, wir sind prä-Threading) in ein Drawable rendern können wollte. Aufgrund der Netzwerkorientierten Struktur von X11 (ein Ergebnis der Mainframearchitektur und der Abwesenheit von so lustigen Sachen wie shared objects) war das auch nicht so sonderlich das Performanceproblem (nur die Leakgefahr besteht dann natürlich weiterhin, SGI Entwickler waren aber noch richtige Männer ;-)

    Über die ganze Diskussion sollte bitte nicht vergessen werden, daß das Argument ohnehin vorgeschoben ist, da das Wayland Protokoll kein spezielles Speichermanagement vorschreibt - Du kannst den Speicher auch in einem extra Daemonclient halten, wenn Dir das Spaß macht.
    Genauso geht rein Clientseitige wie rein Serverseitige Allokation und (vermutlich, daß weiß ich jetzt nicht sicher) sogar Hybride.

    Mittlerweile habe ich mich persönlich wieder beruhigt, da Canonical offensichtlich ohnehin niemanden hat, um ihnen das zu entwickeln (ohne das kompletter Murks dabei rumkommt) - soooo hinterhältig sich in der Öffentlichkeit strunzdumm zu geben und hintenrum Displayserverexperten irgendwo unter Verschluß zu halten sind sie dann wohl hoffentlich doch nicht =)
    Vom ganzen Portierungsaufwand der Toolkits (und sonstiger Anwendungen) mal ganz zu schweigen.

    Es wird also darauf hinauslaufen, daß Canonical in Zukunft irgendeine Androiddistribution auf den "Desktop" (also eben SP+Dock) bringen will - und die "Fragmentierung" haben wir ohnehin schon.

    "Mir" ist dann vermutlich blos PR FUD um ihre eigentlichen Aktionen (was auch immer die dann wirklich sind) zu verschleiern und sich aus dem großspurigen "Wir stehen voll hinter Wayland" rauszulabern.

  9. Re: "serversetige Speicherverwaltung"

    Autor: Thaodan 14.03.13 - 23:23

    lear schrieb:
    --------------------------------------------------------------------------------
    > Über die ganze Diskussion sollte bitte nicht vergessen werden, daß das
    > Argument ohnehin vorgeschoben ist, da das Wayland Protokoll kein spezielles
    > Speichermanagement vorschreibt - Du kannst den Speicher auch in einem extra
    > Daemonclient halten, wenn Dir das Spaß macht.
    > Genauso geht rein Clientseitige wie rein Serverseitige Allokation und
    > (vermutlich, daß weiß ich jetzt nicht sicher) sogar Hybride.
    Wollte das nicht sogar KWin im gewissen Sinne?

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Condor Flugdienst GmbH / FRA HP/B, Neu-Isenburg
  2. Deutsches Krebsforschungszentrum (DKFZ), Heidelberg
  3. Marc Cain GmbH, Bodelshausen
  4. Compiricus AG, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 19,90€
  2. 3,50€
  3. 79,99€ (Release 10. Juni)


Haben wir etwas übersehen?

E-Mail an news@golem.de