Consider having sosreport place itself in a resource constrained cgroup before executing

[portante]

Consider having sosreport place itself in a resource constrained cgroup before executing. On some systems, the amount of CPU and memory needed to perform the collection work can spike and become intrusive. If the admin could specify a cgroup constrained environment in which to run, they might feel more comfortable and not worry about sosreport impacting the system.

[adam-stokes]

Interesting request, however, isn't sosreport mostly diskio bound? What would throttling sosreport's IO for 30 seconds gain us?

[bmr-cymru]

Right: I think we'd need to understand what we're trying to achieve with this. In my tests IO is typically dominant and sos currently uses buffered IO. Afaik the current cgroups blkio controller cannot isolate buffered writes so I don't think this can buy us a great deal. Coincidentally I was thinking about this last night and the work required to convert to O_DIRECT for archive IO so that we don't pollute the page cache during a run (cf. backup tools that use this). It's definitely non-trivial but may be something to work on in the long run.

The next question is how do we do this in a way that avoids imposing policy on administrators who already use cgroups; I'm not sure how we'd do this in a way that's unintrusive and does not conflict with existing system policy and configuration.

There's also a tradeoff here in terms of the time to complete a run vs. the load imposed on the system during the run. We need to be careful to ensure that any changes land us in a 'sweet spot' between the two extremes. If we miss that then we'll upset users either way ('sos takes too long' vs. 'sosreport ate my system').

[TurboTurtle]

I am closing this out alongside #1844 - please see that issue for a more complete answer as to why and what has been investigated.