-----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@xxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx - -- Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx> -----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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
