On Fri, Nov 13, 2020 at 09:46:49AM -0800, Song Liu wrote:
>
>
> > On Nov 12, 2020, at 2:15 PM, Roman Gushchin <g...@fb.com> wrote:
>
> [...]
>
> >
> > +#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?
Thanks!
