On 10/24/21 12:43, Hyeonggon Yoo wrote: >> >> >> >> The main reason for this change is to simplify SLOB a little bit, make >> >> it a bit easier to debug whenever something goes wrong. >> >> >> > >> > It seems acceptable But I wonder it is worth to increase memory usage >> > to allow freeing kmem_cache_alloc-ed objects by kfree()? >> >> Not for the reason above, but for providing a useful API guarantee >> regardless of selected slab allocator IMHO yes. >> > > Mm.. that means some callers free kmem_cache_alloc-ed object using > kfree, and SLAB/SLUB already support that, and SLOB doesn't. Exactly. Finding that out started this whole thread. > In what situations is freeing using kfree needed? > Wouldn't this make code confusing? XFS seems to have good reasons - at some common freeing place objects can appears from multiple caches, and it would be expensive to track their cache just to free them. See https://lore.kernel.org/all/20210930044202.GP2361455@xxxxxxxxxxxxxxxxxxx/ IMHO it really makes sense to support this from API point of view. kmem_cache_alloc() is basically a more specific version of the generic kmalloc(). It makes sense if the generic kind of free, that is kfree() works on those objects too. >> > Thanks, >> > Hyeonggon >> > >> >> meminfo right after the system boot, without the patch: >> >> Slab: 35500 kB >> >> >> >> the same, with the patch: >> >> Slab: 36396 kB >> >> >> > >> >
