# Vorteile CGroups

## wuesti

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

----------

## mv

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.

----------

## wuesti

 *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.

----------

## mv

 *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.

----------

## toralf

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.

----------

## mv

 *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...

----------

## toralf

 *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)

----------

## mv

 *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...

----------

## boospy

Also ich bin seit Jahren mit ondemand glücklich und will ihn durch nix eintauschen.

----------

## toralf

 *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.

----------

## .maverick

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.

----------

## toralf

 *.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

----------

## mv

 *.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.

----------

## toralf

 *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 ?

----------

## mv

 *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.

----------

## toralf

 *.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) ?

----------

## toralf

 *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 :

```

 Waiting for uevents to be processed ... /lib/rc/sh/runscript.sh: 262: read: Illegal option -u

```

----------

## mv

 *toralf wrote:*   

> Hhm, in einem ~x86 UML image bekomme ich :
> 
> ```
> 
>  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. 

```
read -u X var
```

 ist nicht POSIX. POSIX wäre 

```
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).

----------

## toralf

ok : https://bugs.gentoo.org/show_bug.cgi?id=484728

----------

## Eroen

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:

```
/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.

----------

## .maverick

 *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.

----------

## Marlo

 *.maverick wrote:*   

>  ... so wie's aktuell ist ist systemd unter Gentoo einfach benutzbar und in der Grundkonfiguration(!) rasend schnell.

 

++

Ma

----------

## mv

 *.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.

----------

## rogge

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

----------

## schmidicom

 *.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!

 

----------

## mv

 *schmidicom wrote:*   

>  *.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.

 

Erstens mal ist Starten von Daemonen die allerkleinste Aufgabe von Init-Systemen (auch wenn Poettering das anders hinstellen will, weil das die einzige Aufgabe ist, die systemd einigermaßen gut hinbekommt, während es bei so ziemlich allen anderen Aufgaben versagt.)

Zweitens: Bei einem Kommando (start-stop-daemon ...) von "monströsen Scriptgedöns" zu sprechen, ist schon merkwürdig, zumal Du bei systemd da mindestens 3-4 Zeilen benötigst (ExecStart, ExecReload, ExeecStop, KillSigne, Type, PIDFile usw. usf.), von dem ganzen systemd-Drumrum (unit, service, install-Sections) mal ganz abgesehen. Das ist bei systemd also im günstigsten Fall nicht deutlich mehr aufwändig als bei openrc.

Was aber schlimmer ist: Debuggen ist mit systemd praktisch unmöglich. Während es beim Parallelstart mit openrc, wie Du sagst, bei falschen Abhängigkeiten mal zu "zufälligen" Fehlern kommen kann, ist das bei systemd Teil des Konzepts - nur dass Du eben, wenn Du reproduzierbares Verhalten brauchst, nicht die Möglichkeit hast, alles sequentiell zu starten. Schlimmer noch: Wenn Du einen Daemon hast, der das System aufhängt (was in der Praxis durchaus vorkommt: der neue Sound-/Graphic-/Druckertreiber kabbelt sich irgendwie mit den Interrupts mit einem anderen Treiber; u.U. nur manchmal, wenn beide parallel gestartet werden), hast Du nun nicht mehr die Möglichkeit bei jedem Kommando "starten/überspringen/Abbruch" auszuführen, sondern es wird zwangsläufig alles gestartet, so dass Du also im "typischen" Fehlerfall nur noch von einer Rettungs-CD booten kannst (falls Du eine zur Hand hast, und das System einen CD-Leser hat und davon booten kann... durchaus nicht selbstverständlich und schon gar nicht praktisch), und dann musst Du von Hand mit binärer Suche Dienste aktivieren und deaktivieren und ständig neu booten, um herauszufinden, welcher Dienst denn nun den Absturz verursacht. Bei openrc hingegen: "I" "Y" "Y" "Y" "Y" "Y" "Y" (Absturz) - aha, dieses init-file ist die Ursache.

----------

## frostschutz

```
$ zgrep -i cgroup /proc/config.gz 

# CONFIG_CGROUPS is not set
```

 :Wink: 

Aber ich fürchte daß das ne Alterungserscheinung ist. Bei systemd, btrfs und zfs mache ich ja auch nicht mit. pam ist auch deaktiviert. pulseaudio ebenso Fehlanzeige.

Mit Gentoo kann mans ja machen.

EDIT: Sorry, seh gerade erst daß es ja nur noch um Bootgeschwindigkeit geht. Wäre vielleicht was für ein eigenes Thema.

----------

## schmidicom

Also mit der Interaktivität von OpenRC würde ich jetzt nicht unbedingt "Werbung" machen. Erstens ist diese standardmäßig deaktiviert und muss somit vor dem Crash manuell aktiviert werden (kann man auch nachträglich per Live-CD, aber das macht die Sache auch nicht besser), und zweitens ist diese aus gutem Grund standardmäßig deaktiviert denn sie ist mit machen Dingen (plymouth hat z.B. wenig Freude daran) inkompatibel. Dazu kommt das in so einem Scenario alle Treiber (PS2, USB oder noch schlimmer Bluetooth) für die Tastatur schon geladen sein und laufen müssen um interaktiv zu werden, was je nach Kernelkonfiguration auch nicht immer rechtzeitig der Fall ist.

Wenn es unter systemd ein Hintergrunddienst trotz cgroups schafft das ganze System in die Knie zu zwingen kann man durch den Kernelparameter "systemd.unit=rescue.target" dafür sorgen das systemd einen in eine Notfallconsole schickt von wo aus das Problem behoben werden kann. Und selbst wenn das nicht mehr geht kann man mit einer Live-CD (vorzugsweise eine mit systemd wegen journald) immer noch die symlinks in /etc/systemd/system entfernen was aber dank der ersten Lösung eigentlich nicht nötig sein sollte.

----------

## mv

 *schmidicom wrote:*   

> Interaktivität von OpenRC

 

Spar Dir Deine Fehlinformations-Kampagne. Deine an den Haaren herbeigezogenen "Argumente" sind sofort als hanebüchener Unsinn enttarnbar.

Dass Du dem ev. nichtinformierten Leser vorzumachen versuchst, man müsste den interaktiven Modus mit Rettungs-CD toggeln ist schon ein starkes Stück!

Natürlich lässt man den Modus normalerweise an!

 *Quote:*   

> aus gutem Grund standardmäßig deaktiviert

 

Es gibt genau einen guten Grund ihn deaktiviert zu lassen: Wenn man aus Sicherheitsgründen verhindern will, dass ein Nicht-Root-User sehr einfach durch Neubooten gewisse Dienste deaktivieren kann. Dies macht man aber natürlich ohnehin nur auf einem vorher gut getesteten System (bei dem man deswegen den interaktiven Modus auch garantiert nicht braucht).

Alle anderen "Gründe" sind reiner FUD:

 *Quote:*   

> plymouth hat z.B. wenig Freude daran

 

Ein Eyecandy-Tool, das mit systemd gar keine vernünftige Ausgabe liefert, liefert auch mit openrc im interaktiven Modus keine. Und? Wenn man auf das Eyecandy normalerweise nicht verzichten kann, schaltet man es per Grub im Ernstfall ab, wenn man den interaktiven Modus braucht und plymouth tatsächlich den interaktiven Modus verhindern sollte (was ich bezweifle; vermutlich ist halt einfach nur die Ausgabe nicht so schön oder in bestimmten Modi nicht lesbar).

 *Quote:*   

> Dazu kommt das in so einem Scenario alle Treiber (PS2, USB oder noch schlimmer Bluetooth) für die Tastatur schon geladen sein und laufen müssen um interaktiv zu werden

 

Die Tastatur-Interaktivität ist erst mit laufender Tastatur möglich. Eine Wahnsinnserkenntnis und ein Riesenargument, die Interaktivität ganz abzuschalten oder gar ein Iniit-System zu benutzen, dass sie nicht unterstützt! Mannmannmannmann....

Zumal bei praktisch allen Systemen (von den vollkommen exotischen Bluetooth-Only Tastatur-Systemen mal abgesehen [die von den systemd-Fans offensichtlich jedes noch so große Fehlkonzept auf allen Systemen rechtfertigen sollen anstatt - wie es sinnvoll wäre - Protest über die unangemessenen Abhängigkeiten der Bluetooth-Tools unter Linux auszulösen]) die Tastatur mit dem Booten des Kernel oder allerspätestens mit dem Initialisieren der Kernel-Module - der ersten Aktion von openrc - geht.

Ich habe wirklich keine Lust, Deinen Unsinn die ganze Zeit zu zerlegen, aber Deine gezielten Propaganda-Falschinformationen konnte ich einfach nicht so stehen lassen.Last edited by mv on Mon Jan 06, 2014 9:35 pm; edited 1 time in total

----------

## mv

 *frostschutz wrote:*   

> Bei systemd, btrfs und zfs mache ich ja auch nicht mit. pam ist auch deaktiviert. pulseaudio ebenso Fehlanzeige.

 

Diese Dinge haben mit cgroups nun wirklich nichts zu tun. In gewissen Anwendungsfällen mit ganz gezielten Konfigurationen kann cgroups als "verschärfte" chroot ein System sicherer machen. (Die Annahme, dass systemd dies tue, nur weil es irgendwie cgroups nutzt, wäre natürlich ein Kurzschluss).

OK, hier ist eine gewisse Symmetrie zu btfrs und zfs zu sehen: Eine separate noexec,nodev,nosuid-Partition kann auch iher in gewissen Anwendungsfällen als "verschärfte" chroot ein System sicherer machen.

Aber ich hoffe, jedem Leser ist klar, dass das verschiedene "Levels" sind.

Mit Geschwindigkeit hat das alles, wie gesagt, wenig zu tun: Lediglich dass man alle zugehörigen Prozesse "aufsummiert" "nicen" kann, spielt hier eine kleine Rolle, aber das ist eigentlich auch eher nur ein Sicherheitsaspekt, nämlich dass nicht ein Prozess mit niedrigen Rechten zu oft forken kann und damit dann doch das Gesamtsystem in die Knie zwingt.

----------

## frostschutz

 *mv wrote:*   

> Diese Dinge haben mit cgroups nun wirklich nichts zu tun.

 

Hab ich so auch nicht gemeint, war nur ne Feststellung am Rande, daß von dem "neuen Zeugs" viel an mir vorbeigeht.  :Laughing: 

----------

