> On Nov 13, 2020, at 11:40 AM, Roman Gushchin <g...@fb.com> wrote:
>
> 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?
Yeah, that works.
Acked-by: Song Liu <songliubrav...@fb.com>
