Michal Koutný

Thanks for the report. I peeked into the code and this is rather a feature request than bug report. The shielding currently [doesn't](https://github.com/lpechacek/cpuset/blob/master/cpuset/cset.py#L344) [support](https://github.com/lpechacek/cpuset/blob/master/cpuset/cset.py#L408) CPU hotplugging. (I.e. offlining the trailing...

Dropping the CPU exclusivity of the cpuset won't keep the CPUs "shielded" as intended. I don't think this is an approach that would be broadly acceptable. @thiagokokada Do you also...

Thanks for the report. This looks like some of your systemd units use `cpuset` controller (you would see `cpuset` in `/sys/fs/cgroup/cgroup.subtree_control`) and hence it's not available for the shielding to...

`cset shield` takes most of tasks and moves them to a specific cpuset cgroup, so that they're bound to certain set of CPUs and the remaining CPUs are free (shielded)...

I'd like to contribute to the discussion with an extreme perspective -- [ignore all processes](https://github.com/Werkov/systemd/commit/4f6b28a10427d82dafc8f7965ac8125086da83d7) during boot switch_root. Below is a rather lengthier reasoning. Some initrd context here: - initrd...

Hello, @poettering. This is tagged as 'needs-discussion', I've provided some food for thought. I'd like to ask you to consider these arguments and your opinion on them. (It'll be helpful...

Thanks for the quick response. Ad symmetry and leftovers -- I acknowledge proper full cleanup at shutdown (or when switching away from persistent FS) since it's functionally necessary. I consider...

Sorry, what did you mean with: "stuff that excluded itself from the cgroup tree logic"? My (mis)understanding was those were processes in the root cgroup (i.e. excluded from regular cgroup...

@poettering Could you please elaborate more about the keyring helpers that you deemed problematic? (IMO it's similar to the modprobe here, i.e. they shouldn't be killed without warranty.) Also note...

FWIW, there's a planned discussion around this topic on the upcoming [LPC](https://lpc.events/event/16/contributions/1184/).