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
| ||
|
Date: Sun, 9 Jan 2022 14:21:22 +0800 From: Muchun Song <songmuchun@...edance.com> To: Roman Gushchin <guro@...com> Cc: Matthew Wilcox <willy@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...nel.org>, Vladimir Davydov <vdavydov.dev@...il.com>, Shakeel Butt <shakeelb@...gle.com>, Yang Shi <shy828301@...il.com>, Alex Shi <alexs@...nel.org>, Wei Yang <richard.weiyang@...il.com>, Dave Chinner <david@...morbit.com>, trond.myklebust@...merspace.com, anna.schumaker@...app.com, jaegeuk@...nel.org, chao@...nel.org, Kari Argillander <kari.argillander@...il.com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Linux Memory Management List <linux-mm@...ck.org>, linux-nfs@...r.kernel.org, Qi Zheng <zhengqi.arch@...edance.com>, Xiongchun duan <duanxiongchun@...edance.com>, Fam Zheng <fam.zheng@...edance.com>, Muchun Song <smuchun@...il.com>, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, Vlastimil Babka <vbabka@...e.cz> Subject: Re: [PATCH v5 02/16] mm: introduce kmem_cache_alloc_lru On Fri, Jan 7, 2022 at 11:05 AM Roman Gushchin <guro@...com> wrote: > [...] > > /* > > * struct kmem_cache related prototypes > > @@ -425,6 +426,8 @@ static __always_inline unsigned int __kmalloc_index(size_t size, > > > > void *__kmalloc(size_t size, gfp_t flags) __assume_kmalloc_alignment __alloc_size(1); > > void *kmem_cache_alloc(struct kmem_cache *s, gfp_t flags) __assume_slab_alignment __malloc; > > +void *kmem_cache_alloc_lru(struct kmem_cache *s, struct list_lru *lru, > > + gfp_t gfpflags) __assume_slab_alignment __malloc; > > I'm not a big fan of this patch: I don't see why preparing the lru > infrastructure has to be integrated that deep into the slab code. > > Why can't kmem_cache_alloc_lru() be a simple wrapper like (pseudo-code): > void *kmem_cache_alloc_lru(struct kmem_cache *s, struct list_lru *lru, > gfp_t gfpflags) { > if (necessarily) > prepare_lru_infra(); > return kmem_cache_alloc(); > } Hi Roman, Actually, it can. But there is going to be some redundant code similar like memcg_slab_pre_alloc_hook() does to detect the necessity of prepare_lru_infra() in the new scheme of kmem_cache_alloc_lru(). I just want to reduce the redundant overhead. Thanks.
Powered by blists - more mailing lists