From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Dan Streetman <ddstreet@ieee.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Jonathan Corbet <corbet@lwn.net>,
Seth Jennings <sjennings@variantweb.net>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] zswap: update docs for runtime-changeable attributes
Date: Tue, 25 Aug 2015 13:22:24 +0900 [thread overview]
Message-ID: <20150825042224.GB412@swordfish> (raw)
In-Reply-To: <CALZtONDfPBTJNjf+RZxFWtE_qX_dTaxX5c2tx9_D7wuuvju-CQ@mail.gmail.com>
On (08/19/15 11:56), Dan Streetman wrote:
[..]
> > Ugh that's madness. Still, a documented madness is better than an undocumented one.
>
> heh, i'm not sure why it's madness, the alternative of
> uncompressing/recompressing all pages into the new zpool and/or with
> the new compressor seems much worse ;-)
>
Well, I sort of still think that 'change compressor and reboot' is OK. 5cents.
> >
> >>>
> >>>> The zsmalloc type zpool has a more
> >>>> +complex compressed page storage method, and it can achieve greater storage
> >>>> +densities. However, zsmalloc does not implement compressed page eviction, so
> >>>> +once zswap fills it cannot evict the oldest page, it can only reject new pages.
> >>>
> >>> I still wonder why anyone would use zsmalloc with zswap given this limitation.
> >>> It seems only fine for zram which has no real swap as fallback. And even zbud
> >>> doesn't have any shrinker interface that would react to memory pressure, so
> >>> there's a possibility of premature OOM... sigh.
> >>
> >> for situations where zswap isn't expected to ever fill up, zsmalloc
> >> will outperform zbud, since it has higher density.
> >
> > But then you could just use zram? :)
>
> well not *expected* to fill up doesn't mean it *won't* fill up :)
>
> >
> >> i'd argue that neither zbud nor zsmalloc are responsible for reacting
> >> to memory pressure, they just store the pages. It's zswap that has to
> >> limit its size, which it does with max_percent_pool.
> >
> > Yeah but it's zbud that tracks the aging via LRU and reacts to reclaim requests
> > from zswap when zswap hits the limit. Zswap could easily add a shrinker that
> > would relay this requests in response to memory pressure as well. However,
> > zsmalloc doesn't implement the reclaim, or LRU tracking.
>
> I wrote a patch for zsmalloc reclaim a while ago:
>
> https://lwn.net/Articles/611713/
>
> however it didn't make it in, due to the lack of zsmalloc LRU, or any
> proven benefit to zsmalloc reclaim.
>
> It's not really possible to add LRU to zsmalloc, by the nature of its
> design, using the struct page fields directly; there's no extra field
> to use as a lru entry.
Just for information, zsmalloc now registers shrinker callbacks
https://lkml.org/lkml/2015/7/8/497
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Dan Streetman <ddstreet@ieee.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Jonathan Corbet <corbet@lwn.net>,
Seth Jennings <sjennings@variantweb.net>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] zswap: update docs for runtime-changeable attributes
Date: Tue, 25 Aug 2015 13:22:24 +0900 [thread overview]
Message-ID: <20150825042224.GB412@swordfish> (raw)
In-Reply-To: <CALZtONDfPBTJNjf+RZxFWtE_qX_dTaxX5c2tx9_D7wuuvju-CQ@mail.gmail.com>
On (08/19/15 11:56), Dan Streetman wrote:
[..]
> > Ugh that's madness. Still, a documented madness is better than an undocumented one.
>
> heh, i'm not sure why it's madness, the alternative of
> uncompressing/recompressing all pages into the new zpool and/or with
> the new compressor seems much worse ;-)
>
Well, I sort of still think that 'change compressor and reboot' is OK. 5cents.
> >
> >>>
> >>>> The zsmalloc type zpool has a more
> >>>> +complex compressed page storage method, and it can achieve greater storage
> >>>> +densities. However, zsmalloc does not implement compressed page eviction, so
> >>>> +once zswap fills it cannot evict the oldest page, it can only reject new pages.
> >>>
> >>> I still wonder why anyone would use zsmalloc with zswap given this limitation.
> >>> It seems only fine for zram which has no real swap as fallback. And even zbud
> >>> doesn't have any shrinker interface that would react to memory pressure, so
> >>> there's a possibility of premature OOM... sigh.
> >>
> >> for situations where zswap isn't expected to ever fill up, zsmalloc
> >> will outperform zbud, since it has higher density.
> >
> > But then you could just use zram? :)
>
> well not *expected* to fill up doesn't mean it *won't* fill up :)
>
> >
> >> i'd argue that neither zbud nor zsmalloc are responsible for reacting
> >> to memory pressure, they just store the pages. It's zswap that has to
> >> limit its size, which it does with max_percent_pool.
> >
> > Yeah but it's zbud that tracks the aging via LRU and reacts to reclaim requests
> > from zswap when zswap hits the limit. Zswap could easily add a shrinker that
> > would relay this requests in response to memory pressure as well. However,
> > zsmalloc doesn't implement the reclaim, or LRU tracking.
>
> I wrote a patch for zsmalloc reclaim a while ago:
>
> https://lwn.net/Articles/611713/
>
> however it didn't make it in, due to the lack of zsmalloc LRU, or any
> proven benefit to zsmalloc reclaim.
>
> It's not really possible to add LRU to zsmalloc, by the nature of its
> design, using the struct page fields directly; there's no extra field
> to use as a lru entry.
Just for information, zsmalloc now registers shrinker callbacks
https://lkml.org/lkml/2015/7/8/497
-ss
next prev parent reply other threads:[~2015-08-25 4:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 19:07 [PATCH] zswap: update docs for runtime-changeable attributes Dan Streetman
2015-08-18 19:07 ` Dan Streetman
2015-08-19 14:02 ` Vlastimil Babka
2015-08-19 14:02 ` Vlastimil Babka
2015-08-19 14:21 ` Dan Streetman
2015-08-19 14:21 ` Dan Streetman
2015-08-19 15:02 ` Vlastimil Babka
2015-08-19 15:02 ` Vlastimil Babka
2015-08-19 15:56 ` Dan Streetman
2015-08-19 15:56 ` Dan Streetman
2015-08-25 4:22 ` Sergey Senozhatsky [this message]
2015-08-25 4:22 ` Sergey Senozhatsky
2015-08-25 6:22 ` Vlastimil Babka
2015-08-25 6:22 ` Vlastimil Babka
2015-08-24 17:33 ` [PATCHv2] " Dan Streetman
2015-08-24 17:33 ` Dan Streetman
2015-09-04 15:22 ` Vlastimil Babka
2015-09-04 15:22 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150825042224.GB412@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=ddstreet@ieee.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sjennings@variantweb.net \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.