lkml.org 
[lkml]   [2020]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2020-02-20 06:13    [W:0.043 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site