linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vijayanand Jitta <vjitta@codeaurora.org>
To: Christopher Lameter <cl@linux.com>
Cc: penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.or, vinmenon@codeaurora.org,
	kernel-team@android.com
Subject: Re: [PATCH] mm: slub: reinitialize random sequence cache on slab object update
Date: Fri, 31 Jan 2020 12:09:43 +0530	[thread overview]
Message-ID: <1383cd32-1ddc-4dac-b5f8-9c42282fa81c@codeaurora.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2001301826130.9861@www.lameter.com>



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



  reply	other threads:[~2020-01-31  6:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 10:18 [PATCH] mm: slub: reinitialize random sequence cache on slab object update vjitta
2020-01-30 11:17 ` vjitta
2020-02-27 16:53   ` Vlastimil Babka
2020-03-05  5:48     ` vjitta
2020-03-05 12:40       ` Vlastimil Babka
2020-01-30 18:28 ` Christopher Lameter
2020-01-31  6:39   ` Vijayanand Jitta [this message]
2020-02-03  6:57   ` Vijayanand Jitta
2020-02-20  5:12     ` vjitta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1383cd32-1ddc-4dac-b5f8-9c42282fa81c@codeaurora.org \
    --to=vjitta@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.or \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=vinmenon@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).