-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, 2020-06-05 at 15:11 +0100, Richard W.M. Jones wrote:
> On Fri, Jun 05, 2020 at 01:50:29AM -0600, Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 12:33 AM Milan Crha <mc...@redhat.com>
> > wrote:
> > > 
> > > On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote:
> > > > ... The memory used is not preallocated. It's
> > > > dynamically allocated and deallocated, on demand. ...
> > > > 
> > > > The system will use RAM normally up until it's full, and then
> > > > start
> > > > paging out to swap-on-zram, same as a conventional swap-on-
> > > > drive....
> > > 
> > >         Hi,
> > > I confess I've absolutely no idea about this, I mean how that
> > > works in
> > > practice, but when you tell me "we do not allocate on start, we
> > > allocate on demand, when the memory is full", then, I hope a
> > > logic
> > > question is, where do you allocate, when the memory is already
> > > full? If
> > > there's some threshold, then it's quite the same as preallocate
> > > the
> > > memory.
> > 
> > Yes, it's an oversimplification. There isn't a case when the memory
> > is
> > truly completely full. The kernel starts to swap before that, and
> > it
> > can move things around from buffers, cached, and even do reclaim,
> > in
> > order to start allocating memory to the zram device. And at that
> > point
> > the compression permits a greater rate of freed memory due to
> > eviction, than loss due to the allocation to the zram device.
> > 
> > This is taken just now from a laptop with 2+ days uptime
> > 
> > ]$ free -m
> >               total        used        free      shared  buff/cache
> > available
> > Mem:           7845        3292         699         532        3852
> > 3714
> > Swap:          3921         192        3729
> > $ swapon
> > NAME       TYPE      SIZE USED PRIO
> > /dev/zram0 partition 3.8G 193M   -2
> > $ zramctl
> > NAME       ALGORITHM DISKSIZE   DATA COMPR TOTAL STREAMS MOUNTPOINT
> > /dev/zram0 lzo-rle       3.9G 187.3M   50M 52.7M       4 [SWAP]
> > $
> > 
> > This is a small amount of swap in use right now. In this case,
> > ~190M
> > has been paged out to swap, and the zram device has compressed that
> > to
> > ~50M. That's pretty good, so it suggests highly compressible data.
> > The
> > savings is ~140M. That 140M can be used to avoid reclaim of file
> > pages
> > (programs can stay in RAM instead of being pushed out and read back
> > in
> > later) or for more active user data, etc. Anything really.
> 
> I'm unclear: that ~50M is still in RAM?  Or it's compressed on a disk
> somewhere?

IIUC, it takes some part of the RAM and just compresses it on the fly.
For example, I have 32G memory on my laptop and when I enable zram
device, I basically have 23G listed in free as memory and 11G as the
swap. And that 11G is supposed to be compressed memory (in avg cases
with 2:1 ration).

Of course, as part of this change, it will be made that it can't take
more than 4G no matter what by default.

> Also does the swap partition on disk contain compressed pages, or
> uncompressed pages, or a mix of both?

With zram there is no partition on disk, or was this question about
something else?

> Also what is the compression algorithm?  zlib or zstd or something
> else?

zramctl shows ALGORITHM

NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle      11.7G   4K   74B   12K       8 [SWAP]

So it is lzo-rle by default, but it should be possible to override this
algorithm. There is an RFE for this already at zram-generator github.

> The description (I think copied from the kernel documentation) was
> really unclear about how this works.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat   
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog:   
> http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:   
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:   
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:   
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- 
Igor Raits <ignatenkobr...@fedoraproject.org>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aau4ACgkQEV1auJxc
Hh6ZixAAkzA5ABtoIfWP4pzJL4bDu5wIGJMthihc2SGnxEzEGHGfU867AIDr9vFi
RSEckXd7QoGX99XOpxr/rHQznwit1F/icShLZtWAuSQPEOvrLx0YUZMLRW9YUinX
Oz1MyjthdrsKKeKpSP93iIS85HUKM/HJ3z1szyZXgFX8Tkdvn7yUKrGbehXiGBSi
gN9UIurakNRxUP3KuPBaK+A5pXsmL7qgYjXfg8rZIA4NHtaoOkMLY+OUkXvWuXOA
CT61BawWHOkYg31Fvx9XybGRg2p1j9WGb3RbvRJOLbOQeSmcR+xqBPoOC8gdgqy3
nUQMaIvymL6i2YmZE/wCYRrn6pMti3p7JH+kewjWOQMGzsxuB7tvTLYLxj3Y7Bxr
vKOUlmiNByIW1L5t76CPwa0mV+WgMryfyC97+TS46UivOJnid3PZEz8kYZkQmIFF
R2BWJ/SlFaSBkbm4FdIDWpXDnfEeKMrg3k4L4j1NXyctFhSrgctLCoIeP9fCduF2
AoEQ8MgQFanqAxEyeGMNd6ke2grVm3CAwCpbJfWhNE0oJa2uel/sTQa3HgAwqllT
NhrDpEBk45uJd2P6VLgJ9nv0lZ1fK5F2k3CPSVLWXZCalekmOK1UyWwWs/UU3bnP
oeuluAeA6DMZw1d4VE5Kfcq+QzKkYuxQUbVPHuYXXNi2GKRBUck=
=2Sma
-----END PGP SIGNATURE-----
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to