On Wed 15-12-21 18:13:40, Sebastian Andrzej Siewior wrote:

On 2021-12-15 17:56:03 [+0100], Michal Hocko wrote:

quoted

On Wed 15-12-21 17:47:54, Sebastian Andrzej Siewior wrote:

quoted

On 2021-12-13 11:08:26 [+0100], Michal Hocko wrote:

quoted

On Fri 10-12-21 16:22:01, Sebastian Andrzej Siewior wrote:
[...]
I am sorry but I didn't get to read and digest the rest of the message
yet. Let me just point out this

quoted

The problematic part here is mem_cgroup_tree_per_node::lock which can
not be acquired with disabled interrupts on PREEMPT_RT.  The "locking
scope" is not always clear to me.  Also, if it is _just_ the counter,
then we might solve this differently.

I do not think you should be losing sleep over soft limit reclaim. This
is certainly not something to be used for RT workloads and rather than
touching that code I think it makes some sense to simply disallow soft
limit with RT enabled (i.e. do not allow to set any soft limit).

Okay. So instead of disabling it entirely you suggest I should take
another stab at it? Okay. Disabling softlimit, where should I start with
it? Should mem_cgroup_write() for RES_SOFT_LIMIT always return an error
or something else?

Yeah, I would just return an error for RT configuration. If we ever need
to implement that behavior for RT then we can look at specific fixes.

Okay. What do I gain by doing this / how do I test this? Is running
tools/testing/selftests/cgroup/test_*mem* sufficient to test all corner
cases here?

I am not fully aware of all the tests but my point is that if the soft
limit is not configured then there are no soft limit tree manipulations
ever happening and therefore the code is effectivelly dead. Is this
sufficient for the RT patchset to ignore the RT incompatible parts?
-- 
Michal Hocko
SUSE Labs