Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1476105
| From | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC 0/4] ZRAM: make it just store the high compression rate page |
| Date | 2016-09-05 06:00 +0200 |
| Message-ID | <sdTeG-6Fk-15@gated-at.bofh.it> (permalink) |
| References | <s8T5D-3Zg-11@gated-at.bofh.it> <s9Wb7-5Ex-5@gated-at.bofh.it> <s9YcW-6Yd-7@gated-at.bofh.it> <sdRFT-5PN-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web