Re: Fedora 33 System-Wide Change proposal: swap on zram

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote:
> On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr <
> > johnmh@xxxxxxxxxxxxx>
> > wrote:
> > > 
> > > 
> > > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote:
> > 
> > 
> > 
> > > > In discussions with both cloud and server folks, their use
> > > > cases often
> > > > do not even create disk-based swap at all. A small swap-on-zram
> > > > provides all the benefits of inactive anonymous page eviction,
> > > > including reducing reclaim of file pages, without the black
> > > > hole
> > > > performance problems of swap-on-drive.
> > > > 
> > > > 
> > > > 
> > > > So yes it's well suited for these cases and the proposal does
> > > > include
> > > > them. If they wish to be left out, that's up to those working
> > > > groups.
> > > > It's possible to make sure /etc/systemd/zram-generator is not
> > > > present.
> > > 
> > > 
> > > 
> > > That doesn't seem to reflect reality. If you download the Server
> > > image
> > > right now, and go with its automatic partitioning scheme
> > > generation,
> > > it'll give you a swap partition on LVM. This is correct for most
> > > servers,
> > > not necessarily the LVM part, but having swap on disk.
> > 
> > 
> > The proposal recommends changing this. Cloud and Server folks will
> > decide what's best for their use cases, not me.
> 
> In that case, would you be open to changing this proposal to only
> affect 
> Workstation?

I think it is fine to have the proposal as it is. Those groups will
chime in if they do not like this approach. Having things consistent
across editions (in this regard) makes more sense to me tbh.

> -- 
> John M. Harris, Jr.
> 
> _______________________________________________
> 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-----

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7an1kACgkQEV1auJxc
Hh5Ezg/+PrFUmkHOc46SKgDIMa5x3w/SCHOF3VKhpvN4bQ6WWY+HpJhmsh92dvle
ogYnseXIl2wuOyCr75vIMXpuyvBGoZMBlFJmQZG5+2jABJ1/DZ+MyyYgpBWZtkPs
QUoNs03pJ70DHuLjakv4mX9nbXqHPBwOzlQuk07ivdVoj6qTXDhkSpJCBULlBm/N
QsHCIPOoP7Hmu5AZuNopjgzvlr9Ezt3ra/SM65hSxJDNl2Pn/Piex4A35i8+WHgs
iWCvH04iF/+iLt6V09Rya2d+9xWary05DtZdmIRbsR2IjgoYIWtOwC1rp8DsRcL/
nsRODfQuMbP7HB2IihpWIF4A9PATcVP1r+DE7NtlLdSERqrSbTvKcycbsbGww/7b
9IZhhNSRJ0CH4xyRW7R9E6mRHR8K9uYykD8t0eWS7dIlw7mIbDZnwjHYRu1qlQzK
OdgPZkpY9aZkAWWA5iFE3pWIYYmCkRwPPytxFVH4adEqSo0i5xJs0bmbHowthVZ0
zjLQRv/LNxZJTedKgCyLtEt9fb0Gza/8+zrlcmYC1Ahq9+NSWYalFMwRJunRL95b
L9NlTQ8qYUZEAQM9zIL4ULjniUL9lNuq5GIH9OE3JdCvtNY78Ml4u9GjRRX+HwjX
22MQqgNdXQ5tWvcJo2gRDSaUzpIENVvPwY8mUwoEuN4ceYVgnvw=
=RlRQ
-----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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux