Re: [PATCH bpf-next v5 06/34] bpf: prepare for memcg-based memory accounting for bpf maps

On Nov 13, 2020, at 11:40 AM, Roman Gushchin [off-list ref] wrote:

On Fri, Nov 13, 2020 at 09:46:49AM -0800, Song Liu wrote:

quoted

quoted

On Nov 12, 2020, at 2:15 PM, Roman Gushchin [off-list ref] wrote:

[...]

quoted

+#ifdef CONFIG_MEMCG_KMEM
+static __always_inline int __bpf_map_update_elem(struct bpf_map *map, void *key,
+						 void *value, u64 flags)
+{
+	struct mem_cgroup *old_memcg;
+	bool in_interrupt;
+	int ret;
+
+	/*
+	 * If update from an interrupt context results in a memory allocation,
+	 * the memory cgroup to charge can't be determined from the context
+	 * of the current task. Instead, we charge the memory cgroup, which
+	 * contained a process created the map.
+	 */
+	in_interrupt = in_interrupt();
+	if (in_interrupt)
+		old_memcg = set_active_memcg(map->memcg);

set_active_memcg() checks in_interrupt() again. Maybe we can introduce another
helper to avoid checking it twice? Something like

static inline struct mem_cgroup *
set_active_memcg_int(struct mem_cgroup *memcg)
{
       struct mem_cgroup *old;

       old = this_cpu_read(int_active_memcg);
       this_cpu_write(int_active_memcg, memcg);
       return old;
}

Yeah, it's a good idea!

in_interrupt() check is very cheap (like checking some bits in a per-cpu variable),
so I don't think there will be any measurable difference. So I suggest to implement
it later as an enhancement on top (maybe in the next merge window), to avoid an another
delay. Otherwise I'll need to send a patch to mm@, wait for reviews and an inclusion
into the mm tree, etc). Does it work for you?

Yeah, that works. 

Acked-by: Song Liu <redacted>