* [PATCH 1/1] zram: better utilization of zram swap space
[not found] <CGME20171207082647epcas5p4501d88cad78c2c30a522a1857e0f5a02@epcas5p4.samsung.com>
@ 2017-12-07 8:22 ` Gopi Sai Teja
2017-12-07 8:45 ` Sergey Senozhatsky
0 siblings, 1 reply; 5+ messages in thread
From: Gopi Sai Teja @ 2017-12-07 8:22 UTC (permalink / raw)
To: minchan, ngupta, sergey.senozhatsky.work
Cc: linux-kernel, v.narang, pankaj.m, a.sahrawat, prakash.a,
himanshu.sh, Gopi Sai Teja
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.
Tested on ARM:
Before Patch:
class size obj_allocated obj_used pages_used
190 3072 3820 3819 2865
202 3264 65 63 52
254 4096 11791 11791 11791
Total 65604 64616 29504
After Patch:
class size obj_allocated obj_used pages_used
190 3072 4244 4243 3183
202 3264 1500 1499 1200
254 4096 6306 6306 6306
Total 65983 64896 26628
Signed-off-by: Gopi Sai Teja <gopi.st@samsung.com>
---
drivers/block/zram/zram_drv.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 5ece255..f7d9ddd 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -31,8 +31,12 @@ static const unsigned max_num_devices = 32;
/*
* Pages that compress to size greater than this are stored
* uncompressed in memory.
+ * 16 is zsmalloc class interval and unsigned long is extra memory
+ * used by zsmalloc to store metadata.
*/
-static const size_t max_zpage_size = PAGE_SIZE / 4 * 3;
+
+static const size_t max_zpage_size = round_down((PAGE_SIZE / 5 * 4), 16)
+ - sizeof(unsigned long);
/*
* NOTE: max_zpage_size must be less than or equal to:
--
1.9.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1] zram: better utilization of zram swap space
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
2017-12-08 6:11 ` Sergey Senozhatsky
2017-12-11 0:16 ` Minchan Kim
0 siblings, 2 replies; 5+ messages in thread
From: Sergey Senozhatsky @ 2017-12-07 8:45 UTC (permalink / raw)
To: Gopi Sai Teja
Cc: minchan, ngupta, sergey.senozhatsky.work, linux-kernel, v.narang,
pankaj.m, a.sahrawat, prakash.a, himanshu.sh
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1] zram: better utilization of zram swap space
2017-12-07 8:45 ` Sergey Senozhatsky
@ 2017-12-08 6:11 ` Sergey Senozhatsky
2017-12-11 0:16 ` Minchan Kim
1 sibling, 0 replies; 5+ messages in thread
From: Sergey Senozhatsky @ 2017-12-08 6:11 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Gopi Sai Teja, minchan, ngupta, linux-kernel, v.narang, pankaj.m,
a.sahrawat, prakash.a, himanshu.sh
On (12/07/17 17:45), Sergey Senozhatsky wrote:
[..]
> 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".
and yes, I think I'd like to reduce the number of huge classes
right now we store objects [3264+, 4096] in huge clases. with
this patch
lkml.kernel.org/r/1456061274-20059-4-git-send-email-sergey.senozhatsky@gmail.com
we have extra classes and smaller huge-class-range. so we store
objects [3840+, 4096] in huge classes. less huge classes - more
compressed objects; more compressed objects - lower memory usage.
-ss
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1] zram: better utilization of zram swap space
2017-12-07 8:45 ` Sergey Senozhatsky
2017-12-08 6:11 ` Sergey Senozhatsky
@ 2017-12-11 0:16 ` Minchan Kim
2017-12-11 1:55 ` Sergey Senozhatsky
1 sibling, 1 reply; 5+ messages in thread
From: Minchan Kim @ 2017-12-11 0:16 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Gopi Sai Teja, ngupta, linux-kernel, v.narang, pankaj.m,
a.sahrawat, prakash.a, himanshu.sh
Hi Gopi and Sergey,
On Thu, Dec 07, 2017 at 05:45:10PM +0900, Sergey Senozhatsky wrote:
> 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
I agree. zram shouldn't be aware of allocator internal.
It would be better for zram to use *int zs_max_zpage_size(struct zs_pool *pool)*
to set up max_zpage_size.
Let's hide the allocator's detail to the exported function.
Thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1] zram: better utilization of zram swap space
2017-12-11 0:16 ` Minchan Kim
@ 2017-12-11 1:55 ` Sergey Senozhatsky
0 siblings, 0 replies; 5+ messages in thread
From: Sergey Senozhatsky @ 2017-12-11 1:55 UTC (permalink / raw)
To: Minchan Kim
Cc: Sergey Senozhatsky, Gopi Sai Teja, ngupta, linux-kernel,
v.narang, pankaj.m, a.sahrawat, prakash.a, himanshu.sh
On (12/11/17 09:16), Minchan Kim wrote:
[..]
> I agree. zram shouldn't be aware of allocator internal.
> It would be better for zram to use *int zs_max_zpage_size(struct zs_pool *pool)*
> to set up max_zpage_size.
> Let's hide the allocator's detail to the exported function.
Hi Minchan,
cool :)
I'll re-spin the patch [in a day or two]. and then *may be* we can
return to the huge-class watermark proposition. may be there can be
a knob or something of that kind.
-ss
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-12-11 1:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[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
2017-12-08 6:11 ` Sergey Senozhatsky
2017-12-11 0:16 ` Minchan Kim
2017-12-11 1:55 ` Sergey Senozhatsky
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.