All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Gopi Sai Teja <gopi.st@samsung.com>
Cc: minchan@kernel.org, ngupta@vflare.org,
	sergey.senozhatsky.work@gmail.com, linux-kernel@vger.kernel.org,
	v.narang@samsung.com, pankaj.m@samsung.com,
	a.sahrawat@samsung.com, prakash.a@samsung.com,
	himanshu.sh@samsung.com
Subject: Re: [PATCH 1/1] zram: better utilization of zram swap space
Date: Thu, 7 Dec 2017 17:45:10 +0900	[thread overview]
Message-ID: <20171207084510.GA10341@jagdpanzerIV> (raw)
In-Reply-To: <1512634963-1079-1-git-send-email-gopi.st@samsung.com>

On (12/07/17 13:52), Gopi Sai Teja wrote:
> If the length of the compressed page is greater than 75% of the PAGE_SIZE,
> then the page is stored uncompressed in zram space. Zram space utilization
> is improved if the threshold is 80%(5 compressed pages can be stored in
> 4 pages).
> 
> If the compressed length is greater than 3068 and less than 3261, pages
> still can be stored in compressed form in zs_malloc class 3264.
> Currently these compressed pages belong to 4096 zs malloc class.

so this makes sense. I had another idea awhile ago

lkml.kernel.org/r/1456061274-20059-2-git-send-email-sergey.senozhatsky@gmail.com

in short, 3261 is good, but not as good as it possibly can be. for the
time being, our huge-class watermark starts at 3264. but this can
change.


a side note, I think we have sort of wrong API. zsmalloc knows better which
object is huge. and who knows, may be we will change the number of huge
classes someday or huge-class watermark, etc. so having "hey zsmalloc, is
this object huge or not" API seems to be better than ZRAM's enforcement
"hey zsmalloc, this object is huge".

	-ss

  reply	other threads:[~2017-12-07  8:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20171207082647epcas5p4501d88cad78c2c30a522a1857e0f5a02@epcas5p4.samsung.com>
2017-12-07  8:22 ` [PATCH 1/1] zram: better utilization of zram swap space Gopi Sai Teja
2017-12-07  8:45   ` Sergey Senozhatsky [this message]
2017-12-08  6:11     ` Sergey Senozhatsky
2017-12-11  0:16     ` Minchan Kim
2017-12-11  1:55       ` Sergey Senozhatsky

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=20171207084510.GA10341@jagdpanzerIV \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=a.sahrawat@samsung.com \
    --cc=gopi.st@samsung.com \
    --cc=himanshu.sh@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=pankaj.m@samsung.com \
    --cc=prakash.a@samsung.com \
    --cc=v.narang@samsung.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.