* 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, minchan, 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, linux-kernel
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, linux-kernel
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, linux-kernel, 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, linux-kernel
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 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.