On Wed, 21 Mar 2018, Mikulas Patocka wrote: > > You should not be using the slab allocators for these. Allocate higher > > order pages or numbers of consecutive smaller pagess from the page > > allocator. The slab allocators are written for objects smaller than page > > size. > > So, do you argue that I need to write my own slab cache functionality > instead of using the existing slab code? Just use the existing page allocator calls to allocate and free the memory you need. > I can do it - but duplicating code is bad thing. There is no need to duplicate anything. There is lots of infrastructure already in the kernel. You just need to use the right allocation / freeing calls. > > What kind of problem could be caused here? > > Unlocked accesses are generally considered bad. For example, see this > piece of code in calculate_sizes: > s->allocflags = 0; > if (order) > s->allocflags |= __GFP_COMP; > > if (s->flags & SLAB_CACHE_DMA) > s->allocflags |= GFP_DMA; > > if (s->flags & SLAB_RECLAIM_ACCOUNT) > s->allocflags |= __GFP_RECLAIMABLE; > > If you are running this while the cache is in use (i.e. when the user > writes /sys/kernel/slab/<cache>/order), then other processes will see > invalid s->allocflags for a short time. Calculating sizes is done when the slab has only a single accessor. Thus no locking is neeed. Changing the size of objects in a slab cache when there is already a set of object allocated and under management by the slab cache would cause the allocator to fail and lead to garbled data. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
