Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Vorteile CGroups
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
wuesti
Apprentice
Apprentice


Joined: 07 Mar 2009
Posts: 191

PostPosted: Sat Sep 07, 2013 5:55 am    Post subject: Vorteile CGroups Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sat Sep 07, 2013 2:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
wuesti
Apprentice
Apprentice


Joined: 07 Mar 2009
Posts: 191

PostPosted: Sat Sep 07, 2013 7:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sat Sep 07, 2013 7:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3920
Location: Hamburg

PostPosted: Sun Sep 08, 2013 11:06 am    Post subject: Reply with quote

cgroups sind IMO auch notwendig für den CPU scheduler : http://www.heise.de/open/artikel/Kernel-Log-Flinker-mit-Prozessgruppen-1140656.html

Und ich habe es auch aufgegeben, mit cgroup tools dieses Problem hier zu lösen : https://lkml.org/lkml/2013/5/3/376

Evtl.l mach ich da noch mal ein Nörger-thread auf der lkml auf.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Sep 08, 2013 11:47 am    Post subject: Reply with quote

toralf wrote:
cgroups sind IMO auch notwendig für den CPU scheduler

Das meinte ich mit Zeit-Zuteilung u.a....
Quote:
Und ich habe es auch aufgegeben, mit cgroup tools dieses Problem hier zu lösen : https://lkml.org/lkml/2013/5/3/376

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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3920
Location: Hamburg

PostPosted: Sun Sep 08, 2013 11:52 am    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Sep 08, 2013 12:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
boospy
Guru
Guru


Joined: 07 Feb 2010
Posts: 308
Location: Austria

PostPosted: Tue Sep 10, 2013 9:32 pm    Post subject: Reply with quote

Also ich bin seit Jahren mit ondemand glücklich und will ihn durch nix eintauschen.
Back to top
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3920
Location: Hamburg

PostPosted: Wed Sep 11, 2013 9:04 am    Post subject: Reply with quote

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
View user's profile Send private message
.maverick
Apprentice
Apprentice


Joined: 29 Jan 2004
Posts: 159
Location: Bonn

PostPosted: Thu Sep 12, 2013 1:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3920
Location: Hamburg

PostPosted: Thu Sep 12, 2013 4:12 pm    Post subject: Reply with quote

.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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Thu Sep 12, 2013 4:30 pm    Post subject: Reply with quote

.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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3920
Location: Hamburg

PostPosted: Thu Sep 12, 2013 4:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Thu Sep 12, 2013 4:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3920
Location: Hamburg

PostPosted: Thu Sep 12, 2013 5:10 pm    Post subject: Reply with quote

.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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3920
Location: Hamburg

PostPosted: Thu Sep 12, 2013 5:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Thu Sep 12, 2013 9:52 pm    Post subject: Reply with quote

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.
Code:
read -u X var
ist nicht POSIX. POSIX wäre
Code:
read var <&X
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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3920
Location: Hamburg

PostPosted: Fri Sep 13, 2013 8:37 am    Post subject: Reply with quote

ok : https://bugs.gentoo.org/show_bug.cgi?id=484728
Back to top
View user's profile Send private message
Eroen
n00b
n00b


Joined: 20 Dec 2012
Posts: 8
Location: Old World

PostPosted: Fri Sep 13, 2013 9:28 am    Post subject: Reply with quote

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
View user's profile Send private message
.maverick
Apprentice
Apprentice


Joined: 29 Jan 2004
Posts: 159
Location: Bonn

PostPosted: Fri Sep 13, 2013 11:24 am    Post subject: Reply with quote

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
View user's profile Send private message
Marlo
Veteran
Veteran


Joined: 26 Jul 2003
Posts: 1591

PostPosted: Fri Sep 13, 2013 4:15 pm    Post subject: Reply with quote

.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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Fri Sep 13, 2013 8:36 pm    Post subject: Reply with quote

.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
View user's profile Send private message
rogge
Tux's lil' helper
Tux's lil' helper


Joined: 13 Oct 2006
Posts: 132
Location: Erfurt

PostPosted: Sun Jan 05, 2014 9:53 pm    Post subject: Reply with quote

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
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1921
Location: Schweiz

PostPosted: Mon Jan 06, 2014 7:10 am    Post subject: Reply with quote

.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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum