Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1682050 > unrolled thread
| Started by | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| First post | 2017-07-06 07:30 +0200 |
| Last post | 2017-07-06 12:10 +0200 |
| Articles | 3 — 3 participants |
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.
Re: [PATCH v2] zswap: Zero-filled pages handling Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-07-06 07:30 +0200
Re: [PATCH v2] zswap: Zero-filled pages handling Srividya Desireddy <srividya.dr@samsung.com> - 2017-07-06 11:30 +0200
Re: [PATCH v2] zswap: Zero-filled pages handling Dan Streetman <ddstreet@ieee.org> - 2017-07-06 12:10 +0200
| From | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| Date | 2017-07-06 07:30 +0200 |
| Subject | Re: [PATCH v2] zswap: Zero-filled pages handling |
| Message-ID | <u07wt-8qx-1@gated-at.bofh.it> |
On (07/02/17 20:28), Seth Jennings wrote: > On Sun, Jul 2, 2017 at 9:19 AM, Srividya Desireddy > > Zswap is a cache which compresses the pages that are being swapped out > > and stores them into a dynamically allocated RAM-based memory pool. > > Experiments have shown that around 10-20% of pages stored in zswap > > are zero-filled pages (i.e. contents of the page are all zeros), but > > these pages are handled as normal pages by compressing and allocating > > memory in the pool. > > I am somewhat surprised that this many anon pages are zero filled. > > If this is true, then maybe we should consider solving this at the > swap level in general, as we can de-dup zero pages in all swap > devices, not just zswap. > > That being said, this is a fair small change and I don't see anything > objectionable. However, I do think the better solution would be to do > this at a higher level. zero-filled pages are just 1 case. in general, it's better to handle pages that are memset-ed with the same value (e.g. memset(page, 0x01, page_size)). which includes, but not limited to, 0x00. zram does it. -ss
[toc] | [next] | [standalone]
| From | Srividya Desireddy <srividya.dr@samsung.com> |
|---|---|
| Date | 2017-07-06 11:30 +0200 |
| Message-ID | <u0bgJ-2oC-1@gated-at.bofh.it> |
| In reply to | #1682050 |
On Wed, Jul 6, 2017 at 10:49 AM, Sergey Senozhatsky wrote: > On (07/02/17 20:28), Seth Jennings wrote: >> On Sun, Jul 2, 2017 at 9:19 AM, Srividya Desireddy >> > Zswap is a cache which compresses the pages that are being swapped out >> > and stores them into a dynamically allocated RAM-based memory pool. >> > Experiments have shown that around 10-20% of pages stored in zswap >> > are zero-filled pages (i.e. contents of the page are all zeros), but >> > these pages are handled as normal pages by compressing and allocating >> > memory in the pool. >> >> I am somewhat surprised that this many anon pages are zero filled. >> >> If this is true, then maybe we should consider solving this at the >> swap level in general, as we can de-dup zero pages in all swap >> devices, not just zswap. >> >> That being said, this is a fair small change and I don't see anything >> objectionable. However, I do think the better solution would be to do > this at a higher level. > Thank you for your suggestion. It is a better solution to handle zero-filled pages before swapping-out to zswap. Since, Zram is already handles Zero pages internally, I considered to handle within Zswap. In a long run, we can work on it to commonly handle zero-filled anon pages. > zero-filled pages are just 1 case. in general, it's better > to handle pages that are memset-ed with the same value (e.g. > memset(page, 0x01, page_size)). which includes, but not > limited to, 0x00. zram does it. > > -ss It is a good solution to extend zero-filled pages handling to same value pages. I will work on to identify the percentage of same value pages excluding zero-filled pages in Zswap and will get back. - Srividya
[toc] | [prev] | [next] | [standalone]
| From | Dan Streetman <ddstreet@ieee.org> |
|---|---|
| Date | 2017-07-06 12:10 +0200 |
| Message-ID | <u0bTs-2TC-15@gated-at.bofh.it> |
| In reply to | #1682240 |
On Thu, Jul 6, 2017 at 5:29 AM, Srividya Desireddy <srividya.dr@samsung.com> wrote: > On Wed, Jul 6, 2017 at 10:49 AM, Sergey Senozhatsky wrote: >> On (07/02/17 20:28), Seth Jennings wrote: >>> On Sun, Jul 2, 2017 at 9:19 AM, Srividya Desireddy >>> > Zswap is a cache which compresses the pages that are being swapped out >>> > and stores them into a dynamically allocated RAM-based memory pool. >>> > Experiments have shown that around 10-20% of pages stored in zswap >>> > are zero-filled pages (i.e. contents of the page are all zeros), but >>> > these pages are handled as normal pages by compressing and allocating >>> > memory in the pool. >>> >>> I am somewhat surprised that this many anon pages are zero filled. >>> >>> If this is true, then maybe we should consider solving this at the >>> swap level in general, as we can de-dup zero pages in all swap >>> devices, not just zswap. >>> >>> That being said, this is a fair small change and I don't see anything >>> objectionable. However, I do think the better solution would be to do >> this at a higher level. >> > > Thank you for your suggestion. It is a better solution to handle > zero-filled pages before swapping-out to zswap. Since, Zram is already > handles Zero pages internally, I considered to handle within Zswap. > In a long run, we can work on it to commonly handle zero-filled anon > pages. > >> zero-filled pages are just 1 case. in general, it's better >> to handle pages that are memset-ed with the same value (e.g. >> memset(page, 0x01, page_size)). which includes, but not >> limited to, 0x00. zram does it. >> >> -ss > > It is a good solution to extend zero-filled pages handling to same value > pages. I will work on to identify the percentage of same value pages > excluding zero-filled pages in Zswap and will get back. Yes, this sounds like a good modification to the patch. Also, unless anyone else disagrees, it may be good to control this with a module param - in case anyone has a use case that they know won't be helped by this, and the extra overhead of checking each page is wasteful. Probably should default to enabled. > > - Srividya
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web