[PATCH 0/2] memcg, cpuisol: do not interfere pcp cache charges draining with cpuisol workloads

[Michal Hocko <mhocko@kernel.org>]

Leonardo has reported [1] that pcp memcg charge draining can interfere
with cpu isolated workloads. The said draining is done from a WQ context
with a pcp worker scheduled on each CPU which holds any cached charges
for a specific memcg hierarchy. Operation is not really a common
operation [2]. It can be triggered from the userspace though so some
care is definitely due.

Leonardo has tried to address the issue by allowing remote charge
draining [3]. This approach requires an additional locking to
synchronize pcp caches sync from a remote cpu from local pcp consumers.
Even though the proposed lock was per-cpu there is still potential for
contention and less predictable behavior.

This patchset addresses the issue from a different angle. Rather than
dealing with a potential synchronization, cpus which are isolated are
simply never scheduled to be drained. This means that a small amount of
charges could be laying around and waiting for a later use or they are
flushed when a different memcg is charged from the same cpu. More
details are in patch 2. The first patch from Frederic is implementing an
abstraction to tell whether a specific cpu has been isolated and
therefore require a special treatment.

The patchset is on top of Andrew's mm-unstable tree. I am not sure which
tree is the best to route both of them but unless there are any special
requirements for the cpu isolation parts then pushing this via Andrew
seems like the easiest choice.

Frederic Weisbecker (1):
      sched/isolation: Add cpu_is_isolated() API

Michal Hocko (1):
      memcg: do not drain charge pcp caches on remote isolated cpus

 include/linux/sched/isolation.h | 12 ++++++++++++
 mm/memcontrol.c                 |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

[1] https://lore.kernel.org/all/20221102020243.522358-1-leobras@redhat.com/T/#u
[2] https://lore.kernel.org/all/Y9LQ615H13RmG7wL@dhcp22.suse.cz/T/#u
[3] https://lore.kernel.org/all/20230125073502.743446-1-leobras@redhat.com/T/#u