-----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 <mcrha(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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 <ignatenkobrain(a)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-----