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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox