Talk:Cgroups

From ArchWiki

bash script

Perhaps this page should include how to do the famous 200 line kernel patch 4 line bash script? ie. http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html --Unhammer 08:09, 11 January 2011 (EST)

The bash script in question appears to be out-of-date, does anyone have an updated version? RunningDroid (talk) 19:48, 9 June 2013 (UTC)Reply[reply]

Help me understand cgroups

The matlab example given to me is a reason NOT to use cgroups. Why in the world would we want to limit a calculation intensive operation like this it 75 % of the CPU resources? Just nice matlab down to -19 and let it do its thing, I do this all the time with makepkg while I compile for hours. I can use the system and I do not experience any lags while makepkg is calling gcc using all my cores. —This unsigned comment is by Graysky (talk) 13:46, 28 July 2013 (UTC). Please sign your posts with ~~~~!Reply[reply]

My understanding is it's prophylactic not for the pedestrian case but the worst one - the word "can" is the key here
> large calculations in MATLAB can crash your system
dunno your system specs but my own system has lags during larger compiles, and all my build scripts nice them into oblivion.
Sanjeev K Sharma (talk) 17:44, 28 December 2019 (UTC)Reply[reply]

Out-of-date and missing information

This article is a bit outdated.

Wishlist:

  • Split the Cgroups#Ad-hoc groups section into different libcgroup/cgm sections
  • Mention systemd-run and add other systemd service examples and references
  • Mention difference between cgroups v1 and v2 (merged in Linux 4.5)
  • Add specific examples for controlling memory for a new process (libcgroup / cgm / others?)
  • Compare ulimit/setrlimit/limits.conf vs. nice vs. cgroups.

Lekensteyn (talk) 23:23, 9 February 2016 (UTC)Reply[reply]

Rewriting the article.

I am rewriting article on my profile: https://wiki.archlinux.org/index.php/User:Igo95862/cgroups

I am looking for help with style and grammar.

First, the cgmanager is gone. Its been deprecated since 2016 and no longer even works. All cgroups management is done with systemd.

The article show how to run custom cgroups as service, root or user. The user setup is a bit complicated and I had to research it on my own.

I am also planning on adding more useful examples. One idea I had is to limit users to dedicated gpu. I've heard a lot people had issues with games selecting integrated gpu over dedicated. It might be possible to use cgroup to prevent access to igpu under /dev/dri/ but that also might be super broken. I have not tested yet.

Igo95862 (talk) 22:36, 7 December 2019 (UTC)Reply[reply]

should the new article mention how to use cgexec & related progrms

are these now no longer practical to use with cgroups v2?

I had some scripts that used those at the end(non-privileged)-user level but could not get them working under v2.

systemd-run is easier but I will have to get into it more to see if there is finer grained control (especially how to add new (ad-hoc'edly creatd) PIDs to a slice previously started with systemd-run)

If they're no longer practical, perhaps you can explicitly write that in the new article.

Good re-write of the older article, thanks. —This unsigned comment is by Sanjeev K Sharma (talk) 17:40, 28 December 2019 (UTC). Please sign your posts with ~~~~!Reply[reply]

I'm working on drafting a happy medium between the old article and the newer revision. As discussed on IRC, the current edit removed too much information that is still useful in non-systemd contexts, and some information is blatantly incorrect or misleading. wowaname # C 00:52, 6 January 2020 (UTC)Reply[reply]
Article updated, apologies if I got any details wrong but I made a best effort. I'm personally not the most familiar with all the tooling described in the article. wowaname # C 04:46, 10 January 2020 (UTC)Reply[reply]
Sanjeev K Sharma What exactly can't you replicate? Maybe I can help. Using "systemd-run --slice=yourslice" should run the command in the specified slice. Igo95862 (talk) 00:12, 13 January 2020 (UTC)Reply[reply]