Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1338850 > unrolled thread
| Started by | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| First post | 2016-02-21 18:30 +0100 |
| Last post | 2016-02-22 03:30 +0100 |
| Articles | 2 on this page of 22 — 3 participants |
Back to article view | Back to linux.kernel
[RFC][PATCH v2 0/3] mm/zsmalloc: increase objects density and reduce memory wastage Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-02-21 18:30 +0100
[RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-02-21 18:50 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Minchan Kim <minchan@kernel.org> - 2016-02-22 01:10 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 01:40 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Minchan Kim <minchan@kernel.org> - 2016-02-22 02:30 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 03:00 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 03:10 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Minchan Kim <minchan@kernel.org> - 2016-02-22 04:00 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 05:00 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Minchan Kim <minchan@kernel.org> - 2016-02-22 06:00 +0100
Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 06:10 +0100
[RFC][PATCH v2 1/3] mm/zsmalloc: introduce zs_get_huge_class_size_watermark() Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-02-21 19:50 +0100
[RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-02-21 20:00 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Minchan Kim <minchan@kernel.org> - 2016-02-22 01:30 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 01:50 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Minchan Kim <minchan@kernel.org> - 2016-02-22 02:40 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 03:10 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Minchan Kim <minchan@kernel.org> - 2016-02-22 03:40 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 05:00 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Minchan Kim <minchan@kernel.org> - 2016-02-22 05:50 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 11:50 +0100
Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-22 03:30 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| Date | 2016-02-22 11:50 +0100 |
| Subject | Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE |
| Message-ID | <r4WdY-4pR-21@gated-at.bofh.it> |
| In reply to | #1339126 |
On (02/22/16 13:41), Minchan Kim wrote:
[..]
> > oh, sure.
> >
> > so let's keep dynamic page allocation out of sight for now.
> > I'll do more tests with the increase ORDER and if it's OK then
> > hopefully we can just merge it, it's quite simple and shouldn't
> > interfere with any of the changes you are about to introduce.
>
> Thanks.
>
> And as another idea, we could try fallback approach that
> we couldn't meet nr_pages to minimize wastage so let's fallback
> to order-0 page like as-is. It will enhance, at least than now
> with small-amount of code compared to dynmaic page allocation.
speaking of fallback,
with bigger ZS_MAX_ZSPAGE_ORDER 'normal' classes also become bigger.
PATCHED
6 128 0 1 96 78 3 1
7 144 0 1 256 104 9 9
8 160 0 1 128 80 5 5
9 176 0 1 256 78 11 11
10 192 1 1 128 99 6 3
11 208 0 1 256 52 13 13
12 224 1 1 512 472 28 7
13 240 0 1 256 70 15 15
14 256 1 1 64 49 4 1
15 272 0 1 60 48 4 1
BASE
6 128 0 1 96 83 3 1
7 144 0 1 170 113 6 3
8 160 0 1 102 72 4 2
9 176 1 0 93 75 4 4
10 192 0 1 128 104 6 3
11 208 1 1 78 52 4 2
12 224 1 1 511 475 28 4
13 240 1 1 85 73 5 1
14 256 1 1 64 53 4 1
15 272 1 0 45 43 3 1
_techically_, zsmalloc is correct.
for instance, in 11 pages we can store 4096 * 11 / 176 == 256 objects.
256 * 176 == 45056, which is 4096 * 11. so if zspage for class_size 176 will contain 11
order-0 pages, we can count on 0 bytes of unused space once zspage will become ZS_FULL.
but it's ugly, because I think this will introduce bigger internal fragmentation, which,
in some cases, can be handled by compaction, but I'd prefer to touch only ->huge classes
and keep the existing behaviour for normal classes.
so I'm currently thinking of doing something like this
#define ZS_MAX_ZSPAGE_ORDER 2
#define ZS_MAX_HUGE_ZSPAGE_ORDER 4
#define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
#define ZS_MAX_PAGES_PER_HUGE_ZSPAGE (_AC(1, UL) << ZS_MAX_HUGE_ZSPAGE_ORDER)
so, normal classes have ORDER of 2. huge classes, however, as a fallback, can grow
up to ZS_MAX_HUGE_ZSPAGE_ORDER pages.
extend only ->huge classes: pages == 1 && get_maxobj_per_zspage(class_size, pages) == 1.
like this:
static int __get_pages_per_zspage(int class_size, int max_pages)
{
int i, max_usedpc = 0;
/* zspage order which gives maximum used size per KB */
int max_usedpc_order = 1;
for (i = 1; i <= max_pages; i++) {
int zspage_size;
int waste, usedpc;
zspage_size = i * PAGE_SIZE;
waste = zspage_size % class_size;
usedpc = (zspage_size - waste) * 100 / zspage_size;
if (usedpc > max_usedpc) {
max_usedpc = usedpc;
max_usedpc_order = i;
}
}
return max_usedpc_order;
}
static int get_pages_per_zspage(int class_size)
{
/* normal class first */
int pages = __get_pages_per_zspage(class_size,
ZS_MAX_PAGES_PER_ZSPAGE);
/* test if the class is ->huge and try to turn it into a normal one */
if (pages == 1 &&
get_maxobj_per_zspage(class_size, pages) == 1) {
pages = __get_pages_per_zspage(class_size,
ZS_MAX_PAGES_PER_HUGE_ZSPAGE);
}
return pages;
}
-ss
[toc] | [prev] | [next] | [standalone]
| From | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| Date | 2016-02-22 03:30 +0100 |
| Subject | Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE |
| Message-ID | <r4Oq6-769-11@gated-at.bofh.it> |
| In reply to | #1339047 |
On (02/22/16 10:34), Minchan Kim wrote:
[..]
> >
> > that's 891703 - 850147 = 41556 less pages. or 162MB less memory used.
> > 41556 less pages means that zsmalloc had 41556 less chances to fail.
>
>
> Let's think swap-case which is more important for zram now. As you know,
> most of usecase are swap in embedded world.
> Do we really need 16 pages allocator for just less PAGE_SIZE objet
> at the moment which is really heavy memory pressure?
well, it's not about having less PAGE_SIZE sized objects, it's about
allocating less pages in the first place; and to achieve this we need
less PAGE_SIZE sized objects.
in the existing scheme of things (current implementation) allocating
up to 16 pages to end up using less pages looks quite ok.
and not all of the huge classes request 16 pages to become a 'normal' class:
191 3088 1 0 3588 3586 2760 10
192 3104 1 0 3740 3737 2860 13
194 3136 0 1 7215 7208 5550 10
197 3184 1 0 11151 11150 8673 7
199 3216 0 1 9310 9304 7315 11
200 3232 0 1 4731 4717 3735 15
202 3264 0 1 8400 8396 6720 4
206 3328 0 1 22064 22051 17927 13
207 3344 0 1 4884 4877 3996 9
208 3360 0 1 4420 4415 3640 14
211 3408 0 1 11250 11246 9375 5
212 3424 1 0 3344 3343 2816 16
214 3456 0 2 7345 7329 6215 11
217 3504 0 1 10801 10797 9258 6
219 3536 0 1 5295 5289 4589 13
222 3584 0 0 6008 6008 5257 7
223 3600 0 1 1530 1518 1350 15
225 3632 0 1 3519 3514 3128 8
228 3680 0 1 3990 3985 3591 9
230 3712 0 2 2167 2151 1970 10
232 3744 1 2 1848 1835 1694 11
234 3776 0 2 1404 1384 1296 12
235 3792 0 2 672 654 624 13
236 3808 1 2 615 592 574 14
238 3840 1 2 1120 1098 1050 15
254 4096 0 0 241824 241824 241824 1
hm.... I just thought about it. do we have a big enough computation
error in static int get_pages_per_zspage(int class_size)
777 zspage_size = i * PAGE_SIZE;
778 waste = zspage_size % class_size;
779 usedpc = (zspage_size - waste) * 100 / zspage_size;
780
781 if (usedpc > max_usedpc) {
782 max_usedpc = usedpc;
783 max_usedpc_order = i;
784 }
to begin `misconfiguring' the classes? we cast `usedpc' to int, so we can miss
the difference between 90% and 90.95% for example... hm, need to check it later.
so, yes, dynamic page allocation sounds interesting. but should it be part of
this patch set or we can introduce it later (I think we can do it later)?
a good testing for now would be really valuable, hopefully you guys can help
me here. depending on those tests we will have a better road map, I think.
the test I've done (and will do more) demonstrate that we save pages.
-ss
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web