Messages in this thread | | | Date | Thu, 20 Feb 2020 10:42:52 +0530 | From | vjitta@codeauro ... | Subject | Re: [PATCH] mm: slub: reinitialize random sequence cache on slab object update |
| |
On 2020-02-03 12:27, Vijayanand Jitta wrote: > On 1/30/2020 11:58 PM, Christopher Lameter wrote: >> On Thu, 30 Jan 2020, vjitta@codeaurora.org wrote: >> >>> Random sequence cache is precomputed during slab object creation >>> based up on the object size and no of objects per slab. These could >>> be changed when flags like SLAB_STORE_USER, SLAB_POISON are updated >>> from sysfs. So when shuffle_freelist is called during slab_alloc it >> >> Sorry no. That cannot happen. Changing the size of the slab is only >> possible if no slab pages are allocated. Any sysfs changes that affect >> the >> object size must fail if object and slab pages are already allocated. >> >> If you were able to change the object size then we need to prevent >> that >> from happening. >> > > Yes, size of slab can't be changed after objects are allocated, that > holds > true even with this change. Let me explain a bit more about the use > case here > > ZRAM compression uses the slub allocator, by enabling the slub debug > flags like > SLAB_STORE_USER etc.. the memory consumption will rather be increased > which doesn't > serve the purpose of ZRAM compression. So, such flags are to be > disabled before the > allocations happen, this requires updation of random sequence cache as > object > size and number of objects change after these flags are disabled. > > So, the sequence will be > > 1. Slab creation (this will set a precomputed random sequence cache) > 2. Remove the debug flags > 3. update the random sequence cache > 4. Mount zram and then start using it for allocations. > > Thanks, > Vijay
Waiting for your response.
Thanks, Vijay
| |