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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230317134448.11082-1-mhocko@kernel.org>
Date:   Fri, 17 Mar 2023 14:44:46 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Leonardo Bras <leobras@...hat.com>
Cc:     Frederic Weisbecker <fweisbecker@...e.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Shakeel Butt <shakeelb@...gle.com>,
        Muchun Song <muchun.song@...ux.dev>,
        LKML <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>
Subject: [PATCH 0/2] memcg, cpuisol: do not interfere pcp cache charges draining with cpuisol workloads

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