Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1476079 > unrolled thread

Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC 0/4] ZRAM: make it just store the high compression rate page Minchan Kim <minchan@kernel.org> - 2016-09-05 04:20 +0200
    Re: [RFC 0/4] ZRAM: make it just store the high compression rate page Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-09-05 06:00 +0200
    Re: [RFC 0/4] ZRAM: make it just store the high compression rate page Hui Zhu <teawater@gmail.com> - 2016-09-05 07:20 +0200
      Re: [RFC 0/4] ZRAM: make it just store the high compression rate page Minchan Kim <minchan@kernel.org> - 2016-09-05 08:00 +0200
        Re: [RFC 0/4] ZRAM: make it just store the high compression rate page Hui Zhu <teawater@gmail.com> - 2016-09-05 08:10 +0200

#1476079 — Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
> <sergey.senozhatsky.work@gmail.com> wrote:
> > Hello,
> >
> > On (08/22/16 16:25), Hui Zhu wrote:
> >>
> >> Current ZRAM just can store all pages even if the compression rate
> >> of a page is really low.  So the compression rate of ZRAM is out of
> >> control when it is running.
> >> In my part, I did some test and record with ZRAM.  The compression rate
> >> is about 40%.
> >>
> >> This series of patches make ZRAM can just store the page that the
> >> compressed size is smaller than a value.
> >> With these patches, I set the value to 2048 and did the same test with
> >> before.  The compression rate is about 20%.  The times of lowmemorykiller
> >> also decreased.
> >
> > I haven't looked at the patches in details yet. can you educate me a bit?
> > is your test stable? why the number of lowmemorykill-s has decreased?
> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
> >
> > suppose you have X pages that result in bad compression size (from zram
> > point of view). zram stores such pages uncompressed, IOW we have no memory
> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
> > don't try to store those pages in zsmalloc, but keep them as unevictable.
> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
> > improve LMK?
> 
> No, zram will not save this page uncompressed with these patches.  It
> will set it as non-swap and kick back to shrink_page_list.
> Shrink_page_list will remove this page from swapcache and kick it to
> unevictable list.
> Then this page will not be swaped before it get write.
> That is why most of code are around vmscan.c.

If I understand Sergey's point right, he means there is no gain
to save memory between before and after.

With your approach, you can prevent unnecessary pageout(i.e.,
uncompressible page swap out) but it doesn't mean you save the
memory compared to old so why does your patch decrease the number of
lowmemory killing?

A thing I can imagine is without this feature, zram could be full of
uncompressible pages so good-compressible page cannot be swapped out.
Hui, is this scenario right for your case?

Thanks.

[toc] | [next] | [standalone]

#1476105

Hello,

On (09/05/16 11:18), Minchan Kim wrote:
[..]
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
> 
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
> memory compared to old so why does your patch decrease the number of
> lowmemory killing?

you are right Minchan, that was exactly my point. every compressed page
that does not end up in huge_object zspage should result in some memory
saving (somewhere in the range from bytes to kilobytes).

> A thing I can imagine is without this feature, zram could be full of
> uncompressible pages so good-compressible page cannot be swapped out.

a good theory.

in general, a selective compression of N first pages that fall under the
given compression limit is not the same as a selective compression of N
"best" compressible pages. so I'm a bit uncertain about the guarantees
that the patch can provide.

let's assume the following case.
- zram compression size limit set to 2400 bytes (only pages smaller than
  that will be stored in zsmalloc)
- first K pages to swapout have compression size of 2350 +/- 10%
- next L pages have compression size of 2500 +/- 10%
- last M pages are un-compressible - PAGE_SIZE.
- zram disksize can fit N pages
- N > K + L

so instead of compressing and swapping out K + L pages, you would compress
only K pages, leaving (L + M) * PAGE_SIZE untouched. thus I'd say that we
might have bigger chances of LMK/OOM/etc. in some cases.

	-ss

[toc] | [prev] | [next] | [standalone]

#1476121

On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim <minchan@kernel.org> wrote:
> On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
>> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
>> <sergey.senozhatsky.work@gmail.com> wrote:
>> > Hello,
>> >
>> > On (08/22/16 16:25), Hui Zhu wrote:
>> >>
>> >> Current ZRAM just can store all pages even if the compression rate
>> >> of a page is really low.  So the compression rate of ZRAM is out of
>> >> control when it is running.
>> >> In my part, I did some test and record with ZRAM.  The compression rate
>> >> is about 40%.
>> >>
>> >> This series of patches make ZRAM can just store the page that the
>> >> compressed size is smaller than a value.
>> >> With these patches, I set the value to 2048 and did the same test with
>> >> before.  The compression rate is about 20%.  The times of lowmemorykiller
>> >> also decreased.
>> >
>> > I haven't looked at the patches in details yet. can you educate me a bit?
>> > is your test stable? why the number of lowmemorykill-s has decreased?
>> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
>> >
>> > suppose you have X pages that result in bad compression size (from zram
>> > point of view). zram stores such pages uncompressed, IOW we have no memory
>> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
>> > don't try to store those pages in zsmalloc, but keep them as unevictable.
>> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
>> > improve LMK?
>>
>> No, zram will not save this page uncompressed with these patches.  It
>> will set it as non-swap and kick back to shrink_page_list.
>> Shrink_page_list will remove this page from swapcache and kick it to
>> unevictable list.
>> Then this page will not be swaped before it get write.
>> That is why most of code are around vmscan.c.
>
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
>
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
> memory compared to old so why does your patch decrease the number of
> lowmemory killing?
>
> A thing I can imagine is without this feature, zram could be full of
> uncompressible pages so good-compressible page cannot be swapped out.
> Hui, is this scenario right for your case?
>

That is one reason.  But it is not the principal one.

Another reason is when swap is running to put page to zram, what the
system wants is to get memory.
Then the deal is system spends cpu time and memory to get memory. If
the zram just access the high compression rate pages, system can get
more memory with the same amount of memory. It will pull system from
low memory status earlier. (Maybe more cpu time, because the
compression rate checks. But maybe less, because fewer pages need to
digress. That is the interesting part. :)
I think that is why lmk times decrease.

And yes, all of this depends on the number of high compression rate
pages. So you cannot just set a non_swap limit to the system and get
everything. You need to do a lot of test around it to make sure the
non_swap limit is good for your system.

And I think use AOP_WRITEPAGE_ACTIVATE without kicking page to a
special list will make cpu too busy sometimes.
I did some tests before I kick page to a special list. The shrink task
will be moved around, around and around because low compression rate
pages just moved from one list to another a lot of times, again, again
and again.
And all this low compression rate pages always stay together.

Thanks,
Hui


> Thanks.

[toc] | [prev] | [next] | [standalone]

#1476134

On Mon, Sep 05, 2016 at 01:12:05PM +0800, Hui Zhu wrote:
> On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim <minchan@kernel.org> wrote:
> > On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
> >> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
> >> <sergey.senozhatsky.work@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > On (08/22/16 16:25), Hui Zhu wrote:
> >> >>
> >> >> Current ZRAM just can store all pages even if the compression rate
> >> >> of a page is really low.  So the compression rate of ZRAM is out of
> >> >> control when it is running.
> >> >> In my part, I did some test and record with ZRAM.  The compression rate
> >> >> is about 40%.
> >> >>
> >> >> This series of patches make ZRAM can just store the page that the
> >> >> compressed size is smaller than a value.
> >> >> With these patches, I set the value to 2048 and did the same test with
> >> >> before.  The compression rate is about 20%.  The times of lowmemorykiller
> >> >> also decreased.
> >> >
> >> > I haven't looked at the patches in details yet. can you educate me a bit?
> >> > is your test stable? why the number of lowmemorykill-s has decreased?
> >> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
> >> >
> >> > suppose you have X pages that result in bad compression size (from zram
> >> > point of view). zram stores such pages uncompressed, IOW we have no memory
> >> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
> >> > don't try to store those pages in zsmalloc, but keep them as unevictable.
> >> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
> >> > improve LMK?
> >>
> >> No, zram will not save this page uncompressed with these patches.  It
> >> will set it as non-swap and kick back to shrink_page_list.
> >> Shrink_page_list will remove this page from swapcache and kick it to
> >> unevictable list.
> >> Then this page will not be swaped before it get write.
> >> That is why most of code are around vmscan.c.
> >
> > If I understand Sergey's point right, he means there is no gain
> > to save memory between before and after.
> >
> > With your approach, you can prevent unnecessary pageout(i.e.,
> > uncompressible page swap out) but it doesn't mean you save the
> > memory compared to old so why does your patch decrease the number of
> > lowmemory killing?
> >
> > A thing I can imagine is without this feature, zram could be full of
> > uncompressible pages so good-compressible page cannot be swapped out.
> > Hui, is this scenario right for your case?
> >
> 
> That is one reason.  But it is not the principal one.
> 
> Another reason is when swap is running to put page to zram, what the
> system wants is to get memory.
> Then the deal is system spends cpu time and memory to get memory. If
> the zram just access the high compression rate pages, system can get
> more memory with the same amount of memory. It will pull system from
> low memory status earlier. (Maybe more cpu time, because the
> compression rate checks. But maybe less, because fewer pages need to
> digress. That is the interesting part. :)
> I think that is why lmk times decrease.
> 
> And yes, all of this depends on the number of high compression rate
> pages. So you cannot just set a non_swap limit to the system and get
> everything. You need to do a lot of test around it to make sure the
> non_swap limit is good for your system.
> 
> And I think use AOP_WRITEPAGE_ACTIVATE without kicking page to a
> special list will make cpu too busy sometimes.

Yes, and it would same with your patch if new arraival write on CoWed
page is uncompressible data.

> I did some tests before I kick page to a special list. The shrink task

What kinds of test? Could you elaborate a bit more?
shrink task. What does it mean?

> will be moved around, around and around because low compression rate
> pages just moved from one list to another a lot of times, again, again
> and again.
> And all this low compression rate pages always stay together.

I cannot understand with detail description. :(
Could you explain more?

[toc] | [prev] | [next] | [standalone]

#1476135

On Mon, Sep 5, 2016 at 1:51 PM, Minchan Kim <minchan@kernel.org> wrote:
> On Mon, Sep 05, 2016 at 01:12:05PM +0800, Hui Zhu wrote:
>> On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim <minchan@kernel.org> wrote:
>> > On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
>> >> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
>> >> <sergey.senozhatsky.work@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > On (08/22/16 16:25), Hui Zhu wrote:
>> >> >>
>> >> >> Current ZRAM just can store all pages even if the compression rate
>> >> >> of a page is really low.  So the compression rate of ZRAM is out of
>> >> >> control when it is running.
>> >> >> In my part, I did some test and record with ZRAM.  The compression rate
>> >> >> is about 40%.
>> >> >>
>> >> >> This series of patches make ZRAM can just store the page that the
>> >> >> compressed size is smaller than a value.
>> >> >> With these patches, I set the value to 2048 and did the same test with
>> >> >> before.  The compression rate is about 20%.  The times of lowmemorykiller
>> >> >> also decreased.
>> >> >
>> >> > I haven't looked at the patches in details yet. can you educate me a bit?
>> >> > is your test stable? why the number of lowmemorykill-s has decreased?
>> >> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
>> >> >
>> >> > suppose you have X pages that result in bad compression size (from zram
>> >> > point of view). zram stores such pages uncompressed, IOW we have no memory
>> >> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
>> >> > don't try to store those pages in zsmalloc, but keep them as unevictable.
>> >> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
>> >> > improve LMK?
>> >>
>> >> No, zram will not save this page uncompressed with these patches.  It
>> >> will set it as non-swap and kick back to shrink_page_list.
>> >> Shrink_page_list will remove this page from swapcache and kick it to
>> >> unevictable list.
>> >> Then this page will not be swaped before it get write.
>> >> That is why most of code are around vmscan.c.
>> >
>> > If I understand Sergey's point right, he means there is no gain
>> > to save memory between before and after.
>> >
>> > With your approach, you can prevent unnecessary pageout(i.e.,
>> > uncompressible page swap out) but it doesn't mean you save the
>> > memory compared to old so why does your patch decrease the number of
>> > lowmemory killing?
>> >
>> > A thing I can imagine is without this feature, zram could be full of
>> > uncompressible pages so good-compressible page cannot be swapped out.
>> > Hui, is this scenario right for your case?
>> >
>>
>> That is one reason.  But it is not the principal one.
>>
>> Another reason is when swap is running to put page to zram, what the
>> system wants is to get memory.
>> Then the deal is system spends cpu time and memory to get memory. If
>> the zram just access the high compression rate pages, system can get
>> more memory with the same amount of memory. It will pull system from
>> low memory status earlier. (Maybe more cpu time, because the
>> compression rate checks. But maybe less, because fewer pages need to
>> digress. That is the interesting part. :)
>> I think that is why lmk times decrease.
>>
>> And yes, all of this depends on the number of high compression rate
>> pages. So you cannot just set a non_swap limit to the system and get
>> everything. You need to do a lot of test around it to make sure the
>> non_swap limit is good for your system.
>>
>> And I think use AOP_WRITEPAGE_ACTIVATE without kicking page to a
>> special list will make cpu too busy sometimes.
>
> Yes, and it would same with your patch if new arraival write on CoWed
> page is uncompressible data.
>
>> I did some tests before I kick page to a special list. The shrink task
>
> What kinds of test? Could you elaborate a bit more?
> shrink task. What does it mean?
>



Sorry for this part.  It should be function shrink_page_list.

I will do more test for that and post the patch later.

Thanks,
Hui


>> will be moved around, around and around because low compression rate
>> pages just moved from one list to another a lot of times, again, again
>> and again.
>> And all this low compression rate pages always stay together.
>
> I cannot understand with detail description. :(
> Could you explain more?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web