* Re: Zram for FreeBSD [not found] ` <BFFB31F3-F514-453D-AEE5-D1506109CB77@juniper.net> @ 2016-10-06 4:43 ` Sergey Senozhatsky 2016-10-07 17:30 ` Cory Pruce 0 siblings, 1 reply; 5+ messages in thread From: Sergey Senozhatsky @ 2016-10-06 4:43 UTC (permalink / raw) To: Cory Pruce Cc: Nitin Gupta, sergey.senozhatsky.work@gmail.com, minchan@kernel.org, linux-kernel Hi, On (10/05/16 16:47), Cory Pruce wrote: > Could one of you tell me why these compression algo’s were chosen, zram supports more than that. https://marc.info/?l=linux-kernel&m=146469777105130 > if they were implemented as a need for zram, and hm... not all of them (if any at all). lzo, *may be*, was motivated by "compression/decompression perfromance VS compression ratio", which is imporatant for zram. > what the policy is on porting these to FreeBSD? no idea. -ss ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Zram for FreeBSD 2016-10-06 4:43 ` Zram for FreeBSD Sergey Senozhatsky @ 2016-10-07 17:30 ` Cory Pruce 2016-10-10 6:44 ` Sergey Senozhatsky 0 siblings, 1 reply; 5+ messages in thread From: Cory Pruce @ 2016-10-07 17:30 UTC (permalink / raw) To: Sergey Senozhatsky Cc: Nitin Gupta, minchan@kernel.org, linux-kernel@vger.kernel.org Cool, I am starting to get a good grasp on what is going on (I’ll probably need to use FreeBSD’s archive.h as opposed to Linux’s crypto.h). I am trying to get a hold on what exactly I need to port to FreeBSD. I see that (as Nitin suggested) zsmalloc is the main brains of handling the objects and that it creates a fixed amount of sharded “pages” which a compressed (or uncompressed) actual page can span. I see also that that depends on zpool. I will probably find all “dependencies”; however, if one of you could describe the components used/implemented for this, that’d be awesome. Also, any linux specific setup/layout details come to mind? Seriously, any details would be appreciated. It will save me time. Thanks, Cory On 10/5/16, 9:43 PM, "Sergey Senozhatsky" <sergey.senozhatsky.work@gmail.com> wrote: Hi, On (10/05/16 16:47), Cory Pruce wrote: > Could one of you tell me why these compression algo’s were chosen, zram supports more than that. https://marc.info/?l=linux-kernel&m=146469777105130 > if they were implemented as a need for zram, and hm... not all of them (if any at all). lzo, *may be*, was motivated by "compression/decompression perfromance VS compression ratio", which is imporatant for zram. > what the policy is on porting these to FreeBSD? no idea. -ss ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Zram for FreeBSD 2016-10-07 17:30 ` Cory Pruce @ 2016-10-10 6:44 ` Sergey Senozhatsky 2016-10-10 6:55 ` Sergey Senozhatsky 0 siblings, 1 reply; 5+ messages in thread From: Sergey Senozhatsky @ 2016-10-10 6:44 UTC (permalink / raw) To: Cory Pruce Cc: Sergey Senozhatsky, Nitin Gupta, minchan@kernel.org, linux-kernel@vger.kernel.org On (10/07/16 17:30), Cory Pruce wrote: > Cool, I am starting to get a good grasp on what is going on (I’ll probably > need to use FreeBSD’s archive.h as opposed to Linux’s crypto.h). I am trying > to get a hold on what exactly I need to port to FreeBSD. I see that (as Nitin > suggested) zsmalloc is the main brains of handling the objects and that it > creates a fixed amount of sharded “pages” which a compressed (or > uncompressed) actual page can span. I see also that that depends on zpool. zsmalloc doesn't depend on zpool. zpool is an abstraction layer used by zswap. > I will probably find all “dependencies”; however, if one of you could > describe the components used/implemented for this, that’d be awesome. Also, > any linux specific setup/layout details come to mind? there is a whole bunch of hacks that Nitin, Minchan and others used in zsmalloc() to minimize its space consumption (struct page fields re-usage, etc). comments in zsmalloc() can shed some light. -ss ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Zram for FreeBSD 2016-10-10 6:44 ` Sergey Senozhatsky @ 2016-10-10 6:55 ` Sergey Senozhatsky 2016-10-11 16:47 ` Cory Pruce 0 siblings, 1 reply; 5+ messages in thread From: Sergey Senozhatsky @ 2016-10-10 6:55 UTC (permalink / raw) To: Cory Pruce Cc: Nitin Gupta, minchan@kernel.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky you'd also probably want to look at the older zsmalloc version (add compaction and migration later, if need be) https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/mm/zsmalloc.c?id=refs/tags/v4.0 it used to be simpler back then. -ss ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Zram for FreeBSD 2016-10-10 6:55 ` Sergey Senozhatsky @ 2016-10-11 16:47 ` Cory Pruce 0 siblings, 0 replies; 5+ messages in thread From: Cory Pruce @ 2016-10-11 16:47 UTC (permalink / raw) To: Sergey Senozhatsky Cc: Nitin Gupta, minchan@kernel.org, linux-kernel@vger.kernel.org Awesome thanks Sergey. I’ll look through it soon :) On 10/9/16, 11:55 PM, "Sergey Senozhatsky" <sergey.senozhatsky.work@gmail.com> wrote: >you'd also probably want to look at the older zsmalloc version >(add compaction and migration later, if need be) > >https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/mm/zsmalloc.c?id=refs/tags/v4.0 > >it used to be simpler back then. > > -ss ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-11 16:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <FDF35643-03BA-48FE-8CD5-DA6E715875C4@juniper.net>
[not found] ` <BD391BEE-37F1-4048-A48F-248D35245581@juniper.net>
[not found] ` <CAAdovdkndkBoX3jQiUA1YZgjOyixiBSfoPOWW39zxDt0tP_-=w@mail.gmail.com>
[not found] ` <BFFB31F3-F514-453D-AEE5-D1506109CB77@juniper.net>
2016-10-06 4:43 ` Zram for FreeBSD Sergey Senozhatsky
2016-10-07 17:30 ` Cory Pruce
2016-10-10 6:44 ` Sergey Senozhatsky
2016-10-10 6:55 ` Sergey Senozhatsky
2016-10-11 16:47 ` Cory Pruce
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).