Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1496157 > unrolled thread

Re: Zram for FreeBSD

Started bySergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
First post2016-10-06 06:50 +0200
Last post2016-10-11 18:50 +0200
Articles 5 — 2 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.

Contents

  Re: Zram for FreeBSD Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-06 06:50 +0200
    Re: Zram for FreeBSD Cory Pruce <cpruce@juniper.net> - 2016-10-08 00:10 +0200
      Re: Zram for FreeBSD Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-10 08:50 +0200
        Re: Zram for FreeBSD Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-10 09:00 +0200
          Re: Zram for FreeBSD Cory Pruce <cpruce@juniper.net> - 2016-10-11 18:50 +0200

#1496157 — Re: Zram for FreeBSD

FromSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date2016-10-06 06:50 +0200
SubjectRe: Zram for FreeBSD
Message-ID<sp8N3-3Ds-3@gated-at.bofh.it>
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

[toc] | [next] | [standalone]

#1497575

FromCory Pruce <cpruce@juniper.net>
Date2016-10-08 00:10 +0200
Message-ID<spLv3-6HN-5@gated-at.bofh.it>
In reply to#1496157
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

[toc] | [prev] | [next] | [standalone]

#1498141

FromSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date2016-10-10 08:50 +0200
Message-ID<sqCzn-6ly-7@gated-at.bofh.it>
In reply to#1497575
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

[toc] | [prev] | [next] | [standalone]

#1498145

FromSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date2016-10-10 09:00 +0200
Message-ID<sqCJ3-6oI-11@gated-at.bofh.it>
In reply to#1498141
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

[toc] | [prev] | [next] | [standalone]

#1499015

FromCory Pruce <cpruce@juniper.net>
Date2016-10-11 18:50 +0200
Message-ID<sr8pA-DS-15@gated-at.bofh.it>
In reply to#1498145
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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web