<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<span class="ContentPasted0" style="font-size:12pt;margin:0px">Dear all,</span>
<div class="ContentPasted0" style="font-size:12pt;margin:0px">
<div style="margin:0px"><br class="ContentPasted0">
</div>
<div class="ContentPasted0" style="margin:0px">We frequently encounter Slurm in use across the WLCG, which provides us with the slot where we (ALICE) run our job pilots. With the emergence of more multicore oriented workflows, these pilots have since become
highly tasked with managing the resources we have within each slot, so to best utilise the resources given to us. With users often requesting arbitrary resources (cpu and memory in particular), combined with several user payloads running in parallel in the
same slot (as seen by the BQ), this process has in turn become increasingly challenging.</div>
<div style="margin:0px"><br class="ContentPasted0">
</div>
<div class="ContentPasted0" style="margin:0px">One interesting development is the arrival of Cgroups v2, which provides means for unprivileged users to delegate controllers. This is a very useful feature in our use-case, as it would enable further subdividing
the resources given to us within each slot, allowing the pilot to better "box-in" each subjob.</div>
<div style="margin:0px"><br class="ContentPasted0">
</div>
<div class="ContentPasted0" style="margin:0px">That said, in order to delegate controllers (e.g. for memory) to an unprivileged user, that user must be given ownership of the new cgroup given to them by Slurm, as well as the subtree_controller/procs files within
that cgroup.</div>
<div style="margin:0px"><br class="ContentPasted0">
</div>
<div class="ContentPasted0" style="margin:0px">I see that in v22.05, users were already given ownership of the newly created cgroup provided to them (albeit sans the controller files), though this was later changed and removed in commit<span class="ContentPasted0"> </span><a href="https://github.com/SchedMD/slurm/commit/b0e422399f43e81903ead651d8da4430ebb8ec89" title="https://github.com/SchedMD/slurm/commit/b0e422399f43e81903ead651d8da4430ebb8ec89" id="OWA00726505-94c7-aa4e-f560-b50dcef0238a" class="OWAAutoLink ContentPasted0" style="margin:0px">b0e4223</a><span class="ContentPasted0"> </span>-
where the commit message suggests this behaviour should instead be avoided. With the additional permissions on the files that were not delegated at that point, this feature would actually be complete for us. Could you please reconsider supporting unprivileged
cgroups v2? For the record, here is the<span class="ContentPasted0"> </span><a href="https://github.com/SchedMD/slurm/compare/slurm-22.05...zensanp:slurm:slurm-22.05" title="https://github.com/SchedMD/slurm/compare/slurm-22.05...zensanp:slurm:slurm-22.05" id="OWAf596c37b-0552-dd04-9efb-4f913f2bd192" class="OWAAutoLink ContentPasted0" style="margin:0px">diff</a><span class="ContentPasted0"> </span>to
v22.05 that allows us to further slice the allocated slot in smaller chunks.</div>
<div style="margin:0px"><br class="ContentPasted0">
</div>
<div class="ContentPasted0" style="margin:0px">Best regards,</div>
-Maxim Storetvedt</div>
</div>
</body>
</html>