Ugh I think I did not catch up with the docs.

I started with a system that defaults to cgroup v1 but the Slurm doc for that plugin is NOT available at that time. Thus I converted everything to cgroup v2.

It appears that they are both supported and that documentation issue is more on the dev side than admin side.

Thanks for pointing that out. I misinterpreted the "coming soon" part of cgroup v1 plugin and the "legacy" naming for "do not use". It should be fine.

2025年3月27日(木) 0:48 Williams, Jenny Avis jenny_williams@unc.edu:

“ … As cgroup is likely not supposed to be used in newer deployments of Slurm.”

I am curious about this statement. Would someone expand on this, to either support or counter it?

Jenny Williams

UNC Chapel Hill

*From:* Shunran Zhang via slurm-users slurm-users@lists.schedmd.com *Sent:* Wednesday, March 26, 2025 10:52 AM *To:* Gestió Servidors sysadmin.caos@uab.cat *Cc:* Slurm User Community List slurm-users@lists.schedmd.com *Subject:* [slurm-users] Re: Using more cores/CPUs that requested with

If you are letting systemd taking most things over, you got systemd-cgtop that work better than top for your case. There is also systemd-cgls for non-interactive listing.

Also mind to check if you are using cgroup2? A mount to check your cgroup would suffice. As cgroup is likely not supposed to be used in newer deployments of Slurm.

2025年3月26日(水) 17:14 Gestió Servidors via slurm-users < slurm-users@lists.schedmd.com>:

Hello,

Thanks for your answers. I will try now!! One more question: is there any way to check if Cgroups restrictions is working fine during a “running” job or during SLURM scheduling process?

Thanks again!

-- slurm-users mailing list -- slurm-users@lists.schedmd.com To unsubscribe send an email to slurm-users-leave@lists.schedmd.com