View previous topic :: View next topic |
Author |
Message |
wuesti Apprentice
Joined: 07 Mar 2009 Posts: 191
|
Posted: Sat Sep 07, 2013 5:55 am Post subject: Vorteile CGroups |
|
|
Moin Moin,
seit dem Kernelupdate auf 3.10.7-gentoo beschäftige ich mich mit cgroups. Bisher habe ich die Vorteile für einen normalen Anwender, der an einem normalen QuadCore PC mit 4gB arbeitet, nicht erkannt. Ich habe weder Virtualisierungoder mehere CPUs, noch möchte ich Programme in Gruppen zusammenfassen.
Kann jemand den Sinn von cgroups auf einem Gentoo-Desktop mit OpenRC in verständlichen Worten zusammenfassen?
Vielen Dank
wuesti |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Sep 07, 2013 2:19 pm Post subject: |
|
|
Nachdem sich sonst niemand berufen zu fühlen scheint, wage ich mal einen provokativen Versuch:
Ich behaupte mal, für den Normalbenutzer bringt cgroups i.W. gar nichts - es ist einfach nur ein neuer Hype wie systemd, das außer Bloat höchstens theoretische Vorteile bietet (in der Praxis aber eine Menge Konfigurationsaufwand erlaubt - für keinerlei tatsächlichen praktischen Vorteil). Ebenso wie bei Systemd ist auch bei cgroups der Geschwindigkeitsvorteil eine Mär - von Spezialfällen wie virtuellen Servern u.ä. vielleicht abgesehen.
Wenn Du in portage das FEATURE=cgroup aktivierst, hast Du dadurch Deine sandbox etwas "verstärkt" - portage kann dann etwas zuverlässiger im Falle von Bugs die aus dem Ruder gelaufenen Build-Prozesse abbrechen. Anwendungen in der Art sind wohl das Einzige, was Du erwarten kannst, und unterscheiden sich in der Praxis nicht von den bereits bestehenden Lösungen. |
|
Back to top |
|
|
wuesti Apprentice
Joined: 07 Mar 2009 Posts: 191
|
Posted: Sat Sep 07, 2013 7:26 pm Post subject: |
|
|
mv wrote: | Ich behaupte mal, für den Normalbenutzer bringt cgroups i.W. gar nichts - es ist einfach nur ein neuer Hype wie systemd, das außer Bloat höchstens theoretische Vorteile bietet (in der Praxis aber eine Menge Konfigurationsaufwand erlaubt - für keinerlei tatsächlichen praktischen Vorteil). Ebenso wie bei Systemd ist auch bei cgroups der Geschwindigkeitsvorteil eine Mär - von Spezialfällen wie virtuellen Servern u.ä. vielleicht abgesehen. |
Open RC benutzt CGroups. Ich habe mal einen Boot-Test gemacht. Nach 23 Sekunden vom Grub-Prompt ist der Rechner in beiden Konfigurationen gestartet. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Sep 07, 2013 7:34 pm Post subject: |
|
|
wuesti wrote: | Open RC benutzt CGroups. Ich habe mal einen Boot-Test gemacht. Nach 23 Sekunden vom Grub-Prompt ist der Rechner in beiden Konfigurationen gestartet. |
Dass es für die Boot-Zeit keinen Unterschied macht, ist ja klar: Es geht darum, dass im laufenden Betrieb die Daemonen eine angemessenere Zeit-Zuteilung erhalten und ggf. leichter abgeschossen werden können. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3921 Location: Hamburg
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Sep 08, 2013 11:47 am Post subject: |
|
|
toralf wrote: | cgroups sind IMO auch notwendig für den CPU scheduler |
Das meinte ich mit Zeit-Zuteilung u.a....
Ich verstehe Dein Problem nicht ganz: Aktiviere doch einfach On-Demand!? Hier (Intel Core2 mit hardened-sources-3.10.10) gibt es diese Option... |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3921 Location: Hamburg
|
Posted: Sun Sep 08, 2013 11:52 am Post subject: |
|
|
mv wrote: | Aktiviere doch einfach On-Demand!? Hier (Intel Core2 mit hardened-sources-3.10.10) gibt es diese Option... | Ich habe ondemand seit x Jahren aktiv.
Aber der ondemand wird nicht verwendet, wenn gleichzeitig der P-State Treiber selektiert ist. Und den habe ich (mal) selektiert, um herauszufinden, ob der P-State wirklich ein würdiger Nachfolger für den ondemand ist für meine i5 CPU (genau das ist nämlich die Attitüde der Treiberentwickler, den in die Jahre gekommenen ondemand durch was Besseres zu ersetzen).
Meine eigentliche Befürchtung ist, daß der ondemand irgendwann nicht mehr supported wird und der neue Treiber die nice-Prozesse nicht mehr berücksichtigt
(Anmerkung: auch der ondemand wurde seinerzeit erst nachträglich bzgl. der nice-Prozesse verbesert) |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Sep 08, 2013 12:23 pm Post subject: |
|
|
toralf wrote: | Meine eigentliche Befürchtung ist, daß der ondemand irgendwann nicht mehr supported wird und der neue Treiber die nice-Prozesse nicht mehr berücksichtigt
(Anmerkung: auch der ondemand wurde seinerzeit erst nachträglich bzgl. der nice-Prozesse verbesert) |
So wie ich die Kernel-Entwickler einschätze, wird der ondemand nicht aus dem Kernel entfernt werden, bevor der Nachfolger nicht mindestens die selben wichtigen Features hat. Und dieses Feature ist ja nun wirklich nicht unwichtig. Ich würde einfach abwarten... |
|
Back to top |
|
|
boospy Guru
Joined: 07 Feb 2010 Posts: 308 Location: Austria
|
Posted: Tue Sep 10, 2013 9:32 pm Post subject: |
|
|
Also ich bin seit Jahren mit ondemand glücklich und will ihn durch nix eintauschen. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3921 Location: Hamburg
|
Posted: Wed Sep 11, 2013 9:04 am Post subject: |
|
|
boospy wrote: | Also ich bin seit Jahren mit ondemand glücklich und will ihn durch nix eintauschen. | +1
Wenngleich ich /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice standardmäßig auf "1" gesetzt hätte. |
|
Back to top |
|
|
.maverick Apprentice
Joined: 29 Jan 2004 Posts: 159 Location: Bonn
|
Posted: Thu Sep 12, 2013 1:12 pm Post subject: |
|
|
Auch wenn ich mich damit in die Nesseln setzen könnte, aber der Geschwindigkeitsvorteil von systemd ist auf dem Rechner hier real (i.e. 3s vs 15s reine Userspace-Bootzeit, ähnliches beim Herunterfahren). Einer der Vorteile von cgroups ist IIRC, dass du Prozesse, deren Parent stirbt trotzdem noch verfolgen kannst und die nicht einfach unter PID 1 gehangen werden. Das ist abgesehen von Dämonen und der Portage-Sandbox auch noch für Desktop-Sessions durchaus sinnvoll. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3921 Location: Hamburg
|
Posted: Thu Sep 12, 2013 4:12 pm Post subject: |
|
|
.maverick wrote: | Einer der Vorteile von cgroups ist IIRC, dass du Prozesse, deren Parent stirbt trotzdem noch verfolgen kannst und die nicht einfach unter PID 1 gehangen werden. | jo |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu Sep 12, 2013 4:30 pm Post subject: |
|
|
.maverick wrote: | Auch wenn ich mich damit in die Nesseln setzen könnte, aber der Geschwindigkeitsvorteil von systemd ist auf dem Rechner hier real (i.e. 3s vs 15s reine Userspace-Bootzeit, ähnliches beim Herunterfahren) |
Ich vermute, Du rechnest die Zeit zum Starten des Netzwerks mit, das systemd von vornherein nicht unterstützt (oder hast gar wie anscheinend viele andere ein Rechnerupgrade mit Wechsel auf systemd gekoppelt). Vielleicht macht sich bei Dir auch bemerkbar, dass systemd /tmp per Default ins RAM mounted.
openrc mit /bin/sh als Symlink zu dash (das ist wichtig: bash ist schnarchlangsam) hat auf allen meinen Systemen etwa die selbe Bootzeit wie systemd: Hauptzeit kostet in allen Fällen Laden der Kernelmodule und Mounten, danach kommen auf einem Core2 noch 2-4 Sekunden, auf einem langsamen Pentium3 etwa 7-12 Sekunden und auf einem Athlon so dazwischen, bis sich der loginmanager startet. Ausschalten ist bei openrc nur deswegen langsamer, weil fsck beim Shutdown eingestellt ist - auch etwas, was systemd einfach nicht kann. Die Lage der Files auf der Harddisk macht anscheinend deutlich mehr Zeitunterschied aus als systemd<->openrc.
Wie gesagt: Bei der Zeit darf man halt nicht Äpfel mit Birnen vergleichen sondern nur mit einer vergleichbaren Auswahl von gestarteten Diensten beim Booten/Halten. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3921 Location: Hamburg
|
Posted: Thu Sep 12, 2013 4:39 pm Post subject: |
|
|
Quote: | openrc mit /bin/sh als Symlink zu dash | Hhm, ich möchte diesen Symlink nicht ändern, aber könnte openrc nicht einfach gleich die dash verwenden ? |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu Sep 12, 2013 4:43 pm Post subject: |
|
|
toralf wrote: | Quote: | openrc mit /bin/sh als Symlink zu dash | Hhm, ich möchte diesen Symlink nicht ändern, aber könnte openrc nicht einfach gleich die dash verwenden ? |
Da openrc sich an POSIX hält, ist die Benutzung von /bin/sh konsequent.
Inzwischen sollte das Setzen dieses Symlinks aber problemlos sein. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3921 Location: Hamburg
|
Posted: Thu Sep 12, 2013 5:10 pm Post subject: |
|
|
.maverick wrote: | Einer der Vorteile von cgroups ist IIRC, dass du Prozesse, deren Parent stirbt trotzdem noch verfolgen kannst und die nicht einfach unter PID 1 gehangen werden. | HHm, dazu habe ich ja gleich einen Anwendungsfall hier: Beim bisecten von User Mode Linux bugs starte ich eine Reihe von UML Instanzen aus einem Script heraus - manche hängen später dann, das liegt wohl in der Natur der Sache. Wie bekomme ich denn genau von diesen Instanzen die PID raus (ich weis, daß alle mit "linux-" beginnen) ? |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3921 Location: Hamburg
|
Posted: Thu Sep 12, 2013 5:23 pm Post subject: |
|
|
mv wrote: | toralf wrote: | Quote: | openrc mit /bin/sh als Symlink zu dash | Hhm, ich möchte diesen Symlink nicht ändern, aber könnte openrc nicht einfach gleich die dash verwenden ? |
Da openrc sich an POSIX hält, ist die Benutzung von /bin/sh konsequent.
Inzwischen sollte das Setzen dieses Symlinks aber problemlos sein. |
Hhm, in einem ~x86 UML image bekomme ich : Code: |
Waiting for uevents to be processed ... /lib/rc/sh/runscript.sh: 262: read: Illegal option -u
|
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu Sep 12, 2013 9:52 pm Post subject: |
|
|
toralf wrote: | Hhm, in einem ~x86 UML image bekomme ich : Code: |
Waiting for uevents to be processed ... /lib/rc/sh/runscript.sh: 262: read: Illegal option -u
|
|
Das ist ganz klar ein Bug im entsprechenden Startup-File. ist nicht POSIX. POSIX wäre dash hat gegenüber bash den Vor- und Nachteil, dass sie praktisch nur POSIX-kompatible Sachen akzeptiert (von ganz minimalen Erweiterungen wie "local" oder "test ... -nt ..." abgesehen). |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3921 Location: Hamburg
|
|
Back to top |
|
|
Eroen n00b
Joined: 20 Dec 2012 Posts: 8 Location: Old World
|
Posted: Fri Sep 13, 2013 9:28 am Post subject: |
|
|
Sorry I don't German very well, this is based on what was posted on https://bugs.gentoo.org/484728 and could be redundant.
`grep -E 'read\s' /lib/rc/sh/runscript.sh` will tell you that the read builtin is not used in that file at all, most likely the error stems from a script in /etc/init.d .
The command `grep -E 'read.*-u' -r /etc/init.d/` will probably tell you where the issue lies, here it prints:
Code: | /etc/init.d/dmcrypt: while read -u 3 targetline ; do |
This means it might be useful to file a bug against sys-fs/cryptsetup which installs that file. OpenRC itself (which installs the /lib/rc/sh/runscript.sh file) has at least worked well with /bin/sh -> /bin/bb for simple setups, and is not likely to contain major incompatibilities. |
|
Back to top |
|
|
.maverick Apprentice
Joined: 29 Jan 2004 Posts: 159 Location: Bonn
|
Posted: Fri Sep 13, 2013 11:24 am Post subject: |
|
|
mv wrote: | Ich vermute, Du rechnest die Zeit zum Starten des Netzwerks mit, das systemd von vornherein nicht unterstützt (oder hast gar wie anscheinend viele andere ein Rechnerupgrade mit Wechsel auf systemd gekoppelt). Vielleicht macht sich bei Dir auch bemerkbar, dass systemd /tmp per Default ins RAM mounted. | /tmp war bei mir schon immer als tmpfs gemountet und der gesamte Netzwerkkram wurde und wird bei mir von dhcpcd und wpa_supplicant geregelt, da hat auch OpenRC nicht gewartet.
mv wrote: | openrc mit /bin/sh als Symlink zu dash (das ist wichtig: bash ist schnarchlangsam) hat auf allen meinen Systemen etwa die selbe Bootzeit wie systemd |
Das habe ich in der Tat nie probiert, weil (wie bei dem erwähnten Bug) dash bei mir relativ konsequent Ärger gemacht hat.
mv wrote: | Hauptzeit kostet in allen Fällen Laden der Kernelmodule und Mounten |
Da holt systemd durch den sehr einfach zu verwendenden automounter viel heraus, paralleles mounten ging glaube ich auch in OpenRC. Kernelmodule gibt's bei mir nicht viele.
Vielleicht probiere ich irgendwann nochmal OpenRC mit dash, aber zur Zeit benimmt sich systemd bei mir. Die Notwendigkeit von (echten) Skripten um Dämonen zu starten hat sich mir eh nie so richtig erschlossen.
/edit: Nur damit das klar ist, ich bin mit Sicherheit kein Poettering-Fan und das zufällige zusammenziehen von verschiedenen Diensten in systemd missfällt mir auch, aber so wie's aktuell ist ist systemd unter Gentoo einfach benutzbar und in der Grundkonfiguration(!) rasend schnell. |
|
Back to top |
|
|
Marlo Veteran
Joined: 26 Jul 2003 Posts: 1591
|
Posted: Fri Sep 13, 2013 4:15 pm Post subject: |
|
|
.maverick wrote: | ... so wie's aktuell ist ist systemd unter Gentoo einfach benutzbar und in der Grundkonfiguration(!) rasend schnell. |
++
Ma _________________ ------------------------------------------------------------------
http://radio.garden/ |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Fri Sep 13, 2013 8:36 pm Post subject: |
|
|
.maverick wrote: | Da holt systemd durch den sehr einfach zu verwendenden automounter viel heraus |
Höchstens dann, wenn man die meisten Systeme nicht zu Beginn braucht. Davon ab gibt es automounter auch ohne systemd.
Quote: | paralleles mounten |
Ein klassischer Fall, in dem Parallelisieren i.d.R. Zeit kostet. |
|
Back to top |
|
|
rogge Tux's lil' helper
Joined: 13 Oct 2006 Posts: 132 Location: Erfurt
|
Posted: Sun Jan 05, 2014 9:53 pm Post subject: |
|
|
Da es ja hier grad schon um Bootgeschwindigkeit ging, klink' ich mich mal noch mit zwei Fragen ein. Achso: Ich nutze einen Intel Xeon Quad-Core (á 3.2GHz), 12GB RAM und OpenRC, ...
Das erste mal wo es wirklich lange dauert ist gleich am Anfang, wenn
Quote: | Loading Gentoo ................................. | erscheint. Das braucht eine gefühlte Ewigkeit (>7Sek), vor allem bei 4 Kernen sollte ich da mehr erwarten dürfen.
Das zweite mal Pause ist, wenn Quote: | Waiting for uevents to be processed ... | erscheint. Das braucht bestimmt noch mal seine 5 Sek.
Wenn er einmal an ist, ist er auch echt fix.
Hab ich (beim Rechnerwechsel) irgendwas für die Bootzeit elementares vergessen in den Kernel zu kompilieren?
Grüße, rogge |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1921 Location: Schweiz
|
Posted: Mon Jan 06, 2014 7:10 am Post subject: |
|
|
.maverick wrote: | Die Notwendigkeit von (echten) Skripten um Dämonen zu starten hat sich mir eh nie so richtig erschlossen. | Eine echte Notwendigkeit gibt/gab es dafür offensichtlich nicht/nie. Nur hatte man unter init eben keine andere Möglichkeit als für jeden Hintergrunddienst ein regelrecht monströses Scriptgedöns hochzuziehen, wodurch es im Fehlerfall für viele Linuxbenutzer stellenweise fast unmöglich wurde den ganzen Quatsch nachzuvollziehen. Bei der neuen Art Hintergrunddienst zu definieren steigt man wenigstens auch ohne Onlinedoku relativ schnell durch was wann wie gemacht/gestartet wird um den Hintergrunddienst zum laufen zu bekommen, wodurch die Fehlersuche auch einfacher wird.
Und das allein ist für mich momentan Grund genug bei systemd zu bleiben, oder alternativ mal epoch anzutesten.
Zum Thema Geschwindigkeit glaube ich das der grösste Unterschied wohl eher in der funktionierenden Parallelisierung beim starten liegt als bei den cgroups. Bei meinen Versuchen unter OpenRC (rc_parallel="YES" >> /etc/rc.conf) so zu starten gab es immer wieder Probleme dazu noch solche die sich nicht wirklich reproduzieren ließen. Und selbst wenn sich mal ein Problem reproduzieren lasst interessiert das keinen wie man in der rc.conf nachlesen kann, außer man ist Programmierer und behebt den Fehler gleich selbst.
rc.conf wrote: | Don't file bugs about this unless you can supply patches that fix it without breaking other things! |
_________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
|