Re: [PATCH] mm/list_lru: allocate on first insert instead of allocation

[Vlastimil Babka <vbabka@suse.cz>]

On 2/28/25 18:18, Vlastimil Babka wrote:
> On 2/28/25 17:34, Johannes Weiner wrote:
>> On Fri, Feb 28, 2025 at 07:38:36PM +0800, Jingxiang Zeng wrote:
>>> @@ -84,6 +86,9 @@ lock_list_lru_of_memcg(struct list_lru *lru, int nid, struct mem_cgroup *memcg,
>>>  			spin_unlock_irq(&l->lock);
>>>  		else
>>>  			spin_unlock(&l->lock);
>>> +	} else {
>>> +		if (!memcg_list_lru_alloc(memcg, lru))
>>> +			goto again;
>>>  	}
>> 
>> Unfortunately, you can't do allocations from this path :(
>> 
>> list_lru_add() is called from many places with spinlocks, rcu locks
>> etc. held.
> 
> Aww, I was hoping we'd get rid of all the plumbing of lru through the slab
> allocator.
> But maybe we could, anyway? In __memcg_slab_post_alloc_hook() AFAICS the
> only part that lru handling reuses is the objcg pointer. Moving the code to
> kmem_cache_alloc_lru() would mean just another current_obj_cgroup() lookup
> and that's not that expensive in the likely() cases, or is it?

At the time it was introduced by commit 88f2ef73fd66 ("mm: introduce
kmem_cache_alloc_lru") there was get_obj_cgroup_from_current() which seems
much more involved - looking up memcg first, then ojbcg from that, with a
obj_cgroup_tryget(). The tradeoff might be different today and not warrant
the lru parameter anymore.