Fedora 33 System-Wide Change proposal: swap on zram

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/SwapOnZRAM

== Summary ==

Swap is useful, except when it's slow. zram is a RAM drive that uses
compression. Create a swap-on-zram during start-up. And no longer use
swap partitions by default.


== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email: chrismurphy(a)fedoraproject.org

== Detailed Description ==

==== zram Basic function ====

The zram† device, typically <span style=color:brown>/dev/zram0</span>,
has a size set at create time during early boot, by zram-generator†
per its configuration file. The memory used is not preallocated. It's
dynamically allocated and deallocated, on demand. Due to compression,
a full <span style=color:brown>/dev/zram0</span> uses half as much
memory as its size.

The <span style=color:brown>/dev/zram0</span> behaves like any other
block device. It can be formatted with a file system, or mkswap, which
is the intention with this change proposal.

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. The
zram driver starts to allocate memory at roughly 1/2 the rate of page
outs, due to compression. But, there is no free lunch. This means
swap-on-zram is not as effective at page eviction as swap-on-drive,
the eviction rate is ~50% instead of 100%. But it is at least an order
of magnitude faster than drive based swap.

zram has about 0.1% overhead or ~1MiB/1GiB. If the workload never
touches swap, this overhead is the sole cost. In practice when not
used at all, feature owner has experienced ~0.04% overhead.

Example: A system has 16 GiB RAM. The proposed defaults suggest the
<span style=color:brown>/dev/zram0</span> device will be 4 GiB. If the
workload completely fills up swap with 4 GiB of anonymous pages,
what's happened? The <span style=color:red>zramctl</span> command will
display the true compression ratio. If 2:1 is really obtained, it
means 4GiB swap data is compressed to 2GiB. Therefore 2GiB is the
actual RAM usage, and is also the net effective eviction. i.e. 4 GiB
anonymous pages are evicted, but are then compressed and pinned into 2
GiB RAM, for a net memory savings of 2 GiB.

†</br >
[https://www.kernel.org/doc/Documentation/blockdev/zram.txt kernel.org zram.txt]

[https://github.com/systemd/zram-generator Github zram-generator project]


==== Overview of the Feature ====

Using swap is a good idea†, but no one likes it when it's slow.
Anaconda and Fedora IoT have been using swap-on-zram by default for
years. This builds on their prior effort.


There are three components to the change:

# Install systemd rust-zram-generator† package. This does not enable
swap-on-zram, it only makes the generator available.</br >
# Install a default zram-generator configuration. When present,
swap-on-zram is set-up during startup.</br >
# Do not create swap partition/LV with default installations.

This proposal aims to apply all three, for all Fedora editions and
spins, by default.

It further aims to apply the first two, for upgrades and custom installations.

It might be useful to only make the generator available (1), should an
edition/spin wish to opt out, or as a fallback if applying the feature
to upgrades fails to withstand scrutiny.

†</br >
There is a tl;dr section at the top. Highly recommend reading the
whole article. [https://chrisdown.name/2018/01/02/in-defence-of-swap.html
In defence of swap: common misconceptions]


==== Default zram device configuration: ====

During startup, create a zram device <span
style=color:brown>/dev/zram0</span>, with a size equal to 50% RAM, but
capped† to 4 GiB, and with a higher than typical swap priority†.

These values seem reasonably conservative, and are based on prior work
in Fedora. Anaconda sets swap-on-drive sized to 50% RAM in the no
hibernation case, common outside x86. Fedora IoT's implementation also
sets swap-on-zram size to 50% RAM.

†</br >
[https://github.com/systemd/zram-generator/issues/10 RFE: should be
able to set a cap on zram device size #10]

[https://github.com/systemd/zram-generator/issues/8 RFE: should set priority #8]


==== Default installer behavior  ====

The installer is currently responsible for creating a swap-on-drive
device. This will be dropped. The zram-generator + configuration file
will trigger the setup and activation of swap-on-zram. This means
hibernation isn't possible, even on systems that could support it.

Please see [https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
Supporting hibernation in Workstation edition] for much more detailed
information, including why it's increasingly likely hibernation isn't
possible anyway, and a path to improving hibernation support.


==== Custom/Advance partitioning installer behavior ====

The user can add swap using Custom partitioning at install time. This
is swap-on-drive. And the installer will also include the <span
style=color:red> resume=UUID </span> kernel parameter for this swap
device. No change in behavior here.

Since swap-on-zram is still enabled by default, there will be two
swaps: swap-on-zram, and swap-on-drive. The swap-on-zram will have
higher priority, thus being favored over drive based swap. The kernel
is smart enough to know it can't hibernate to a zram device, and will
instead use drive based swap.


==== How can it be disabled? ====

Immediately:</br >
<span style=color:red>swapoff /dev/zram0</span>

Permanently:</br >
<span style=color:red>rm /etc/systemd/zram-generator.conf</span>


== Feedback ==

==== You're enabling it on upgrades? ====

That's the current plan. As a technical matter, feature owner is
confident this feature will improve the experience of all users
regardless of configuration. As a non-technical matter, it's
recognized that (a) ''hey pal, you're messing with my customizations,
not cool!'' and (b) ''swap always stinks, I don't care if it has a
'Z'
in the name!'' may need more convincing.

There are possible risks.

* Workloads that expect full use of memory, and depend on 100% page
eviction. These may run slower if they really need full use of memory,
but some memory is used for the zram device instead. Such workloads
might favor zswap.

* Workloads with low compressible pages. In the worst case, this means
unnecessary work merely moving pages around.

* Workloads with memory full, and hibernation. Hibernation is already
stressful to memory-management subsystem and prone to bailing out in
such cases. The swap-on-zram will be favored for evictions in the
attempt to free memory to create the hibernation image. It could
increase instances of hibernation entry failure. This isn't a crash,
it just means the attempt doesn't succeed, and the system resumes
operation instead of hibernating.

While possible, it's difficult to estimate their probability. But this
is a significant consideration in the conservative default zram size.
Users can easily increase zram size as needed for their use case,
simply by editing <span
style=color:red>/etc/systemd/zram-generator.conf</span> and the change
takes effect at next boot.

==== Why systemd zram-generator? ====

It's the most upstream implementation to date, is fast and
lightweight. The zram-generator uses existing systemd infrastructure
to setup the zram block device, format it as swap, and swapon - all
during early boot. It's very similar in behavior to fstab-generator,
gpt-auto-generator, and cryptsetup-generator†.

Converging on one implementation avoids user confusion. And while the
alternatives are nice and work fine, a systemd generator is
particularly well suited for this use case compared to a systemd
service unit.†

Also, it's an reference implementation of a system generator written in Rust.

†</br >
[https://www.freedesktop.org/software/systemd/man/systemd.generator.html
freedesktop.org About systemd generators.]</br >
[https://lists.fedoraproject.org/archives/list/[e-mail].o...
devel@ ''Re: swap-on-zram by default'' Zbigniew Jędrzejewski-Szmek,
systemd zram-generator author/maintainer]


==== Why not a bigger zram device? ====

The main idea of being conservative is to address concerns about
upgrades. It's possible some workloads will have less compressible
data. Hence, not going with <span style=color:brown>/dev/zram0</span>
sized to 100% of RAM at this time. Even a <span
style=color:brown>/dev/zram0</span> of 200% RAM is not unreasonable
*if* the compression ratio is at least 2:1. However, it's possible a
system can get "stuck" in a kind of swap thrashing similar to
conventional swap-on-drive, except it's CPU and memory bound, rather
than IO bound. Feature owner thinks it's better to just oom, instead
of getting overly aggressive with the zram device size.

Conversely it's possible to be too conservative with the size, and
result in more instances of OOM kill. If applying the feature to
upgrades is rejected, it's probably reasonable to increase the cap to
~8GiB. Of course more feedback and testing is needed, and it will be
taken into consideration.

Note that the kernel zram doc says an excessively sized zram device
does come with overhead. Users's can increase the size easily
post-install, a capability they don't easily have with swap-on-drive.
The goal for Fedora 33 is a default that's useful and safe for the
vast majority of use cases.


==== Why not zswap? ====

Zswap† is a similar idea, but with a totally different implementation.
It is swap specific, uses a RAM cache, and requires a conventional
swap partition existing already. It might be true certain workloads
are better suited for using zswap. But swap-on-zram depends only on
volatile storage. This is simpler and it's more secure. Whereas zswap
"spills over" into swap-on-drive and will leak user data if that swap
device isn't encrypted. Some workloads may do better with zswap, and
it's a valid future feature for a new generator, or possibly extend
zram-generator to support it via the configuration file. Maybe the
generator could favor zswap when swap-on-drive already exists; and
fallback to swap-on-zram?

†</br >
[https://www.kernel.org/doc/Documentation/vm/zswap.txt kernel.org zswap.txt]


== Benefit to Fedora ==

* significantly improves system responsiveness, especially when swap
is under pressure;
* more secure, user data leaks into swap are on volatile media;
* without swap-on-drive, there's better utilization of a limited
resource: benefit of swap without the drive space consumption;
* complements on-going resource control work, including earlyoom;
* further reduces the time to out-of-memory kill, when workloads exceed limits;
* improves performance for both "no swap" and "existing swap" setups;



== Scope ==

* Proposal owners:
** add zram-generator package to comps and kickstarts as appropriate
** obsolete zram package (used by Fedora IoT)
** means of per edition/spin configurations, if needed
** coordinate a test day

* Other developers:
**Anaconda are agreeable to deprecating their built-in implementation
in favor of swap-on-zram
**RFE's for zram-generator: users are not worse off if they don't
happen. Open request for help, to make it possible. It's much
appreciated.</br >
[https://github.com/systemd/zram-generator/issues/10 RFE: should be
able to set a cap on zram device size #10]</br >
[https://github.com/systemd/zram-generator/issues/8 RFE: should set priority #8]

* Release engineering: [https://pagure.io/releng/issues #9495]

* Policies and guidelines: N/A

* Trademark approval: N/A


== Upgrade/compatibility impact ==

Add Supplements:fedora-release-common to zram-generator to pull it in
on upgrades.

Existing systems without swap will have swap-on-zram enabled.

Existing systems with swap-on-drive, will also have swap-on-zram
enabled (two swap devices), with higher priority for the zram device.
Existing swap-on-drive will not be removed.

'zram' package contains zram-swap.service and associated bash scripts,
and is currently used by Fedora IoT and ARM spins. It will be
obsoleted to avoid conflicting/duplicative swap-on-zram
implementations.


== How To Test ==

Any hardware. Any version of Fedora.

# dnf install zram-generator
# cp /usr/share/doc/zram-generator/zram-generator.conf.example
/etc/systemd/zram-generator.conf
# Edit the configuration
# Reboot
# Check that swap is on a zram device: zramctl, swapon
# Detailed check: journalctl -b -o short-monotonic | grep 'swap\|zram'
# Check that priority is higher than existing swap if two or more are
listed. ## (Enhancement is needed for this.)

Suggested configuration file values:</br >
<span style=color:red>[zram0]</span></br >
<span style=color:red>memory-limit = none</span></br >
<span style=color:red>zram-fraction = 0.5</span></br >

Feel free to run your usual workloads more aggressively or in
parallel. Suspend-to-RAM and suspend-to-drive are expected to continue
to work too (or at least hit all the same bugs as without zram being
used).

Also, you can see the actual compression ratio achieved with the
following command:</br >
<span style=color:red> zramctl </span>


==== Test Day ====

[https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to
discover edge cases, and tweak the default configuration if necessary
to establish a good one-size-fits all approach.


== User Experience ==

The user won't notice anything displeasing. If their usual workload
causes them to dread swap thrashing, they'll be surprised that
thrashing doesn't happen. The user might get curious if they don't
find a swap entry in /etc/fstab. Or if they 'swapon' and see swap
pointing to <span style=color:brown>/dev/zram0</span> instead of a
drive partition or LV.


== Dependencies ==

N/A


== Contingency Plan ==

* Contingency mechanism: Don't ship the generator = big hammer, but
easy. Preferable to ship the generator, but only selectively ship
configuration files = scalpel, pretty easy.
* Contingency deadline: Beta freeze
* Blocks release? No.
* Blocks product? No.


== Documentation ==

Consider adding a hint in an /etc/fstab comment? There is no man page
for this, and the documentation is also minimal, besides what's in
this feature proposal. It's an open question how the user should get
more information on how to configure and tweak it. But then, they
don't have that for swap today either. There's just institutional
knowledge.

Hence, a strong test day, with a lot of people and press coverage of
the feature, might help spread the word for institutional knowledge
changes coming.

Ideas welcome.


== Release Notes ==
Pending feedback and test day.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Milan Crha]

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.

Let aside how the compression itself works. Does it mean, that the
actual outcome will be quicker response (than when using swap on disk)
for a price of higher requirements on the CPU (thus it can
compress/decompress in a timely manner), thus eventually higher power
consumption, thus shorter up time, before the battery is down? I know I
can easily misunderstand things, but it feels like a side effect of the
compression.

Virtual machines. I usually do not give it access to the all host
system resources, I give it like 1 or 2 CPUs (sometimes more, but only
when I know I want to do something expensive there), and like 2GB of
memory (I used to give it one, but since Fedora begun to require at
least 2, I increased it). With this swap to RAM on, should I give it
even more memory (and eventually CPU), thus Fedora can boot and work
reasonably well?

When you've a machine with 4GB RAM and 1TB HDD and 1.6GHz CPU, it's
much cheaper to use swap on disk than to waste RAM, which should be
used for other things (it's even not fully usable 4GB, because some of
that can use integrated graphics card). I guess this will penalize such
low cost machines, though it needs testing to know for sure. There are
devices with a lot less resources (there had been mentioned IoT, under
which, I suppose, belong also toys like Raspberry PI, which do not have
a lot of RAM (not counting Raspberry PI 4B)), where it might (or might
not) hurt even more.

My main machine has 16GB RAM. When I run compilation of some bigger
projects (like WebKitGTK in my case, but I do not want to even think of
giants like LibreOffice), then I face memory pressures, also depending
on the target type (debug/release) and how many cores I give to it. It
happens from time to time that the whole system freezes (keyboard/mouse
doesn't react, neither Caps Lock/Num Lock), with high CPU usage. I
suppose it tries to compile, but I never left it run that long, I just
turn off the machine and start again, where the new run eventually
survives. Should this swap to RAM help anyhow in such situation?

>  [https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to
>  discover edge cases, and tweak the default configuration if necessary
>  to establish a good one-size-fits all approach. 
The developer usage and average (office) user usage are very different.
I'm afraid you cannot find any number, which will fit to all.
	Bye,
	Milan

[Kevin Kofler]

Ben Cotton wrote:
>  Swap is useful, except when it's slow. zram is a RAM drive that
> uses
>  compression. Create a swap-on-zram during start-up. And no longer use
>  swap partitions by default.
>  
>  == Owner ==
>  * Name: [[User:chrismurphy| Chris Murphy]]
>  * Email: chrismurphy(a)fedoraproject.org 
I do not think it is safe to assume that zram is sufficient to completely 
replace disk swap. We do not know how much RAM is actually available on all 
users' machines, and the compressibility of RAM contents depends on the 
individual user's workloads.

So, I am opposed to this change as is.

>  # Install systemd rust-zram-generator† package. This does not enable
>  swap-on-zram, it only makes the generator available. 
Also -1 to adding something to the core system that is written in a language 
for which we do not even have dynamic linking support. Or even real static 
linking support, as opposed to packaging libraries as source code.

        Kevin Kofler

[Frantisek Zatloukal]

I am +1 for this change, I don't have any numbers but from day-to-day
usage, both my systems seem far more responsive when swapping to zram
instead of swap.

On Fri, Jun 5, 2020 at 8:56 AM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  I do not think it is safe to assume that zram is sufficient to
> completely
>  replace disk swap. We do not know how much RAM is actually available on
>  all
>  users' machines, and the compressibility of RAM contents depends on the
>  individual user's workloads.
>  
I believe having zram as a high priority swap and then normal swap with
lower priority to be used when zram gets filled up might be an option too
(I am not saying we should go that route, just mentioning it's a
possibility).

[Igor Raits]

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

On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>  
>  == Summary ==
>  
>  Swap is useful, except when it's slow. zram is a RAM drive that uses
>  compression. Create a swap-on-zram during start-up. And no longer use
>  swap partitions by default.
>  
>  
>  == Owner ==
>  * Name: [[User:chrismurphy| Chris Murphy]]
>  * Email: chrismurphy(a)fedoraproject.org 
Thank you for really detailed an simple to understand description. This
is how I'd like to see change proposals being written :)

>  == Detailed Description ==
>  
>  ==== zram Basic function ====
>  
>  The zram† device, typically <span
>  style=color:brown>/dev/zram0</span>,
>  has a size set at create time during early boot, by zram-generator†
>  per its configuration file. The memory used is not preallocated. It's
>  dynamically allocated and deallocated, on demand. Due to compression,
>  a full <span style=color:brown>/dev/zram0</span> uses half as much
>  memory as its size.
>  
>  The <span style=color:brown>/dev/zram0</span> behaves like any other
>  block device. It can be formatted with a file system, or mkswap,
>  which
>  is the intention with this change proposal.
>  
>  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. The
>  zram driver starts to allocate memory at roughly 1/2 the rate of page
>  outs, due to compression. But, there is no free lunch. This means
>  swap-on-zram is not as effective at page eviction as swap-on-drive,
>  the eviction rate is ~50% instead of 100%. But it is at least an
>  order
>  of magnitude faster than drive based swap.
>  
>  zram has about 0.1% overhead or ~1MiB/1GiB. If the workload never
>  touches swap, this overhead is the sole cost. In practice when not
>  used at all, feature owner has experienced ~0.04% overhead.
>  
>  Example: A system has 16 GiB RAM. The proposed defaults suggest the
>  <span style=color:brown>/dev/zram0</span> device will be 4 GiB. If
>  the
>  workload completely fills up swap with 4 GiB of anonymous pages,
>  what's happened? The <span style=color:red>zramctl</span> command
>  will
>  display the true compression ratio. If 2:1 is really obtained, it
>  means 4GiB swap data is compressed to 2GiB. Therefore 2GiB is the
>  actual RAM usage, and is also the net effective eviction. i.e. 4 GiB
>  anonymous pages are evicted, but are then compressed and pinned into
>  2
>  GiB RAM, for a net memory savings of 2 GiB. 
I basically have same questions as Milan Crha in the other reply to
this post.

>  †</br >
>  [https://www.kernel.org/doc/Documentation/blockdev/zram.txt
>  kernel.org zram.txt]
>  
>  [https://github.com/systemd/zram-generator Github zram-generator
>  project]
>  
>  
>  ==== Overview of the Feature ====
>  
>  Using swap is a good idea†, but no one likes it when it's slow.
>  Anaconda and Fedora IoT have been using swap-on-zram by default for
>  years. This builds on their prior effort.
>  
>  
>  There are three components to the change:
>  
>  # Install systemd rust-zram-generator† package. This does not enable
>  swap-on-zram, it only makes the generator available.</br >
>  # Install a default zram-generator configuration. When present,
>  swap-on-zram is set-up during startup.</br >
>  # Do not create swap partition/LV with default installations.
>  
>  This proposal aims to apply all three, for all Fedora editions and
>  spins, by default.
>  
>  It further aims to apply the first two, for upgrades and custom
>  installations.
>  
>  It might be useful to only make the generator available (1), should
>  an
>  edition/spin wish to opt out, or as a fallback if applying the
>  feature
>  to upgrades fails to withstand scrutiny.
>  
>  †</br >
>  There is a tl;dr section at the top. Highly recommend reading the
>  whole article. [  
>  https://chrisdown.name/2018/01/02/in-defence-of-swap.html
>  In defence of swap: common misconceptions]
>  
>  
>  ==== Default zram device configuration: ====
>  
>  During startup, create a zram device <span
>  style=color:brown>/dev/zram0</span>, with a size equal to 50% RAM,
>  but
>  capped† to 4 GiB, and with a higher than typical swap priority†.
>  
>  These values seem reasonably conservative, and are based on prior
>  work
>  in Fedora. Anaconda sets swap-on-drive sized to 50% RAM in the no
>  hibernation case, common outside x86. Fedora IoT's implementation
>  also
>  sets swap-on-zram size to 50% RAM.
>  
>  †</br >
>  [https://github.com/systemd/zram-generator/issues/10 RFE: should be
>  able to set a cap on zram device size #10]
>  
>  [https://github.com/systemd/zram-generator/issues/8 RFE: should set
>  priority #8]
>  
>  
>  ==== Default installer behavior  ====
>  
>  The installer is currently responsible for creating a swap-on-drive
>  device. This will be dropped. The zram-generator + configuration file
>  will trigger the setup and activation of swap-on-zram. This means
>  hibernation isn't possible, even on systems that could support it.
>  
>  Please see [  
>  https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
>  Supporting hibernation in Workstation edition] for much more detailed
>  information, including why it's increasingly likely hibernation isn't
>  possible anyway, and a path to improving hibernation support.
>  
>  
>  ==== Custom/Advance partitioning installer behavior ====
>  
>  The user can add swap using Custom partitioning at install time. This
>  is swap-on-drive. And the installer will also include the <span
>  style=color:red> resume=UUID </span> kernel parameter for this swap
>  device. No change in behavior here.
>  
>  Since swap-on-zram is still enabled by default, there will be two
>  swaps: swap-on-zram, and swap-on-drive. The swap-on-zram will have
>  higher priority, thus being favored over drive based swap. The kernel
>  is smart enough to know it can't hibernate to a zram device, and will
>  instead use drive based swap.
>  
>  
>  ==== How can it be disabled? ====
>  
>  Immediately:</br >
>  <span style=color:red>swapoff /dev/zram0</span>
>  
>  Permanently:</br >
>  <span style=color:red>rm /etc/systemd/zram-generator.conf</span>
>  
>  
>  == Feedback ==
>  
>  ==== You're enabling it on upgrades? ====
>  
>  That's the current plan. As a technical matter, feature owner is
>  confident this feature will improve the experience of all users
>  regardless of configuration. As a non-technical matter, it's
>  recognized that (a) ''hey pal, you're messing with my customizations,
>  not cool!'' and (b) ''swap always stinks, I don't care if it has a
>  'Z'
>  in the name!'' may need more convincing.
>  
>  There are possible risks.
>  
>  * Workloads that expect full use of memory, and depend on 100% page
>  eviction. These may run slower if they really need full use of
>  memory,
>  but some memory is used for the zram device instead. Such workloads
>  might favor zswap.
>  
>  * Workloads with low compressible pages. In the worst case, this
>  means
>  unnecessary work merely moving pages around.
>  
>  * Workloads with memory full, and hibernation. Hibernation is already
>  stressful to memory-management subsystem and prone to bailing out in
>  such cases. The swap-on-zram will be favored for evictions in the
>  attempt to free memory to create the hibernation image. It could
>  increase instances of hibernation entry failure. This isn't a crash,
>  it just means the attempt doesn't succeed, and the system resumes
>  operation instead of hibernating.
>  
>  While possible, it's difficult to estimate their probability. But
>  this
>  is a significant consideration in the conservative default zram size.
>  Users can easily increase zram size as needed for their use case,
>  simply by editing <span
>  style=color:red>/etc/systemd/zram-generator.conf</span> and the
>  change
>  takes effect at next boot.
>  
>  ==== Why systemd zram-generator? ====
>  
>  It's the most upstream implementation to date, is fast and
>  lightweight. The zram-generator uses existing systemd infrastructure
>  to setup the zram block device, format it as swap, and swapon - all
>  during early boot. It's very similar in behavior to fstab-generator,
>  gpt-auto-generator, and cryptsetup-generator†.
>  
>  Converging on one implementation avoids user confusion. And while the
>  alternatives are nice and work fine, a systemd generator is
>  particularly well suited for this use case compared to a systemd
>  service unit.†
>  
>  Also, it's an reference implementation of a system generator written
>  in Rust.
>  
>  †</br >
>  [  
>  https://www.freedesktop.org/software/systemd/man/systemd.generator.html
>  freedesktop.org About systemd generators.]</br >
>  [  
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  devel@ ''Re: swap-on-zram by default'' Zbigniew Jędrzejewski-Szmek,
>  systemd zram-generator author/maintainer]
>  
>  
>  ==== Why not a bigger zram device? ====
>  
>  The main idea of being conservative is to address concerns about
>  upgrades. It's possible some workloads will have less compressible
>  data. Hence, not going with <span style=color:brown>/dev/zram0</span>
>  sized to 100% of RAM at this time. Even a <span
>  style=color:brown>/dev/zram0</span> of 200% RAM is not unreasonable
>  *if* the compression ratio is at least 2:1. However, it's possible a
>  system can get "stuck" in a kind of swap thrashing similar to
>  conventional swap-on-drive, except it's CPU and memory bound, rather
>  than IO bound. Feature owner thinks it's better to just oom, instead
>  of getting overly aggressive with the zram device size.
>  
>  Conversely it's possible to be too conservative with the size, and
>  result in more instances of OOM kill. If applying the feature to
>  upgrades is rejected, it's probably reasonable to increase the cap to
>  ~8GiB. Of course more feedback and testing is needed, and it will be
>  taken into consideration.
>  
>  Note that the kernel zram doc says an excessively sized zram device
>  does come with overhead. Users's can increase the size easily
>  post-install, a capability they don't easily have with swap-on-drive.
>  The goal for Fedora 33 is a default that's useful and safe for the
>  vast majority of use cases.
>  
>  
>  ==== Why not zswap? ====
>  
>  Zswap† is a similar idea, but with a totally different
>  implementation.
>  It is swap specific, uses a RAM cache, and requires a conventional
>  swap partition existing already. It might be true certain workloads
>  are better suited for using zswap. But swap-on-zram depends only on
>  volatile storage. This is simpler and it's more secure. Whereas zswap
>  "spills over" into swap-on-drive and will leak user data if that swap
>  device isn't encrypted. Some workloads may do better with zswap, and
>  it's a valid future feature for a new generator, or possibly extend
>  zram-generator to support it via the configuration file. Maybe the
>  generator could favor zswap when swap-on-drive already exists; and
>  fallback to swap-on-zram?
>  
>  †</br >
>  [https://www.kernel.org/doc/Documentation/vm/zswap.txt kernel.org
>  zswap.txt]
>  
>  
>  == Benefit to Fedora ==
>  
>  * significantly improves system responsiveness, especially when swap
>  is under pressure;
>  * more secure, user data leaks into swap are on volatile media;
>  * without swap-on-drive, there's better utilization of a limited
>  resource: benefit of swap without the drive space consumption;
>  * complements on-going resource control work, including earlyoom;
>  * further reduces the time to out-of-memory kill, when workloads
>  exceed limits;
>  * improves performance for both "no swap" and "existing swap"
> setups;
>  
>  
>  
>  == Scope ==
>  
>  * Proposal owners:
>  ** add zram-generator package to comps and kickstarts as appropriate
>  ** obsolete zram package (used by Fedora IoT)
>  ** means of per edition/spin configurations, if needed
>  ** coordinate a test day
>  
>  * Other developers:
>  **Anaconda are agreeable to deprecating their built-in implementation
>  in favor of swap-on-zram
>  **RFE's for zram-generator: users are not worse off if they don't
>  happen. Open request for help, to make it possible. It's much
>  appreciated.</br >
>  [https://github.com/systemd/zram-generator/issues/10 RFE: should be
>  able to set a cap on zram device size #10]</br >
>  [https://github.com/systemd/zram-generator/issues/8 RFE: should set
>  priority #8]
>  
>  * Release engineering: [https://pagure.io/releng/issues #9495]
>  
>  * Policies and guidelines: N/A
>  
>  * Trademark approval: N/A
>  
>  
>  == Upgrade/compatibility impact ==
>  
>  Add Supplements:fedora-release-common to zram-generator to pull it in
>  on upgrades. 
I would do it other way around just to keep logic sane.

>  Existing systems without swap will have swap-on-zram enabled.
>  
>  Existing systems with swap-on-drive, will also have swap-on-zram
>  enabled (two swap devices), with higher priority for the zram device.
>  Existing swap-on-drive will not be removed. 
It would be nice to see this in action, what kind of issues this might
bring.

>  'zram' package contains zram-swap.service and associated
> bash
>  scripts,
>  and is currently used by Fedora IoT and ARM spins. It will be
>  obsoleted to avoid conflicting/duplicative swap-on-zram
>  implementations.
>  
>  
>  == How To Test ==
>  
>  Any hardware. Any version of Fedora.
>  
>  # dnf install zram-generator
>  # cp /usr/share/doc/zram-generator/zram-generator.conf.example
>  /etc/systemd/zram-generator.conf
>  # Edit the configuration
>  # Reboot
>  # Check that swap is on a zram device: zramctl, swapon
>  # Detailed check: journalctl -b -o short-monotonic | grep
>  'swap\|zram'
>  # Check that priority is higher than existing swap if two or more are
>  listed. ## (Enhancement is needed for this.)
>  
>  Suggested configuration file values:</br >
>  <span style=color:red>[zram0]</span></br >
>  <span style=color:red>memory-limit = none</span></br >
>  <span style=color:red>zram-fraction = 0.5</span></br >
>  
>  Feel free to run your usual workloads more aggressively or in
>  parallel. Suspend-to-RAM and suspend-to-drive are expected to
>  continue
>  to work too (or at least hit all the same bugs as without zram being
>  used).
>  
>  Also, you can see the actual compression ratio achieved with the
>  following command:</br >
>  <span style=color:red> zramctl </span> 
I would appreciate here how to get to the state from swap-on-disk
(default workstation) to the new swap-on-zram (new default
workstation). So that people can see better how they would be affected
by this change.

>  
>  ==== Test Day ====
>  
>  [https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to
>  discover edge cases, and tweak the default configuration if necessary
>  to establish a good one-size-fits all approach.
>  
>  
>  == User Experience ==
>  
>  The user won't notice anything displeasing. If their usual workload
>  causes them to dread swap thrashing, they'll be surprised that
>  thrashing doesn't happen. The user might get curious if they don't
>  find a swap entry in /etc/fstab. Or if they 'swapon' and see swap
>  pointing to <span style=color:brown>/dev/zram0</span> instead of a
>  drive partition or LV.
>  
>  
>  == Dependencies ==
>  
>  N/A
>  
>  
>  == Contingency Plan ==
>  
>  * Contingency mechanism: Don't ship the generator = big hammer, but
>  easy. Preferable to ship the generator, but only selectively ship
>  configuration files = scalpel, pretty easy.
>  * Contingency deadline: Beta freeze
>  * Blocks release? No.
>  * Blocks product? No.
>  
>  
>  == Documentation ==
>  
>  Consider adding a hint in an /etc/fstab comment? There is no man page
>  for this, and the documentation is also minimal, besides what's in
>  this feature proposal. It's an open question how the user should get
>  more information on how to configure and tweak it. But then, they
>  don't have that for swap today either. There's just institutional
>  knowledge.
>  
>  Hence, a strong test day, with a lot of people and press coverage of
>  the feature, might help spread the word for institutional knowledge
>  changes coming.
>  
>  Ideas welcome.
>  
>  
>  == Release Notes ==
>  Pending feedback and test day.
>  
>  
>  -- 
>  Ben Cotton
>  He / Him / His
>  Senior Program Manager, Fedora & CentOS Stream
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
>  To unsubscribe send an email to    
>  devel-announce-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/[e-mail]...
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z86UACgkQEV1auJxc
> Hh6FVw//ZPNbzWgiCAUalQk4Ih5Zn7Z8HrpReej00arKuu+DhtsOWaUXr5iEwIIB
> ZVWgpEPn40DKLn0OiAzDCFM+DRpReGXIlmUnnz3fV+NCE23snQ1gG4ucu/97mExo
> heFl8ndBpJj3BF9oXrHhSumX3hHhQu3Kq6xWMj3Wr33Ao+v+/+vQpPqPGFGM+XV+
> tAN7ljf1MVDSJxbTyXsykzxAwfq66hUFY+8/t7H0/OWzbq6uplsRXgeN5/wvW9NX
> wjWldQPes3kpuzMAnWwWb5dfVW+zhRoUnc2cyp3ZMrkc25re7Wf7gveZE4t0p3X3
> ku5SjHj+MTzeWTvFg8YqygdVUpliprvOeewStAd9fpUZt8BRl4MD1g80NDVpXCO1
> mz9v/zUNnTGNmosth/EBOIfm66uzJQuWOru+I4oTezwuP6YZIxIONULj4XPMSjlI
> CGt9gC+Jpl4/IDSI0Vk+zEFGywpcxnqHidwZOdi8fgjyE4E2GWLwOwRpqL1T1CCe
> gPyqPGhBlhayvA4yx2ixAtjn6v56bTPNADtyD10hw71XmC19uEW337asPYNrVMyu
> aRvgLX2n/Lwr/n6URysLbb7APTaFZANhbiVnDJBIzEIU5hI3Vzp7GLGXojr2gRvH
> bPIxYvsJr2xFMJ1tAIQwreHaxTFlO2wODUgSz0sVZQaQch71KWc=
> =Hce9
> -----END PGP SIGNATURE-----

[Chris Murphy]

On Fri, Jun 5, 2020 at 12:33 AM Milan Crha <mcrha(a)redhat.com&gt; 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.



>  Let aside how the compression itself works. Does it mean, that the
>  actual outcome will be quicker response (than when using swap on disk)
>  for a price of higher requirements on the CPU (thus it can
>  compress/decompress in a timely manner), thus eventually higher power
>  consumption, thus shorter up time, before the battery is down? I know I
>  can easily misunderstand things, but it feels like a side effect of the
>  compression. 
I'm not sure I can quantify the battery consumption aspect. I've been
using this configuration for a year and haven't noticed a difference
in battery life, or heat. But in the case of heavy swap, it's
remarkably faster than SSD. For HDD it's an even bigger difference.
The writes to either drive type also comes with a power cost. I'm not
sure which one is more efficient.

>  Virtual machines. I usually do not give it access to the all host
>  system resources, I give it like 1 or 2 CPUs (sometimes more, but only
>  when I know I want to do something expensive there), and like 2GB of
>  memory (I used to give it one, but since Fedora begun to require at
>  least 2, I increased it). With this swap to RAM on, should I give it
>  even more memory (and eventually CPU), thus Fedora can boot and work
>  reasonably well? 
No. I also use VM's and I leave the zram device configured at 50% RAM
which is 4GiB for both of my laptops.

And in fact, I've been using swap-on-zram in the guest VM too, instead
of swap-on-drive. These are 2-3GiB VMs.


>  When you've a machine with 4GB RAM and 1TB HDD and 1.6GHz CPU,
> it's
>  much cheaper to use swap on disk than to waste RAM, which should be
>  used for other things (it's even not fully usable 4GB, because some of
>  that can use integrated graphics card). I guess this will penalize such
>  low cost machines, though it needs testing to know for sure. There are
>  devices with a lot less resources (there had been mentioned IoT, under
>  which, I suppose, belong also toys like Raspberry PI, which do not have
>  a lot of RAM (not counting Raspberry PI 4B)), where it might (or might
>  not) hurt even more. 
These are really good questions. I have an Intel NUC with 4GiB RAM,
and Raspberry Pi Zero with only 512M RAM, and I use swap-on-zram there
too because (a) swap on SD Card is terrible performance (b) SD Cards
have pretty low max lifetime writes so I try to reduce writes as much
as possible to increase their life (c) Fedora IoT and I think some of
the other ARM products have been using swap-on-zram sized to 50% RAM
by default in Fedora for years.

It's actually very well suited for the low memory device, as well as
desktop and servers with tons of memory. And cloudy things as well.


>  My main machine has 16GB RAM. When I run compilation of some bigger
>  projects (like WebKitGTK in my case, but I do not want to even think of
>  giants like LibreOffice), then I face memory pressures, also depending
>  on the target type (debug/release) and how many cores I give to it. It
>  happens from time to time that the whole system freezes (keyboard/mouse
>  doesn't react, neither Caps Lock/Num Lock), with high CPU usage. I
>  suppose it tries to compile, but I never left it run that long, I just
>  turn off the machine and start again, where the new run eventually
>  survives. Should this swap to RAM help anyhow in such situation? 
Yes. The webkitgtk compile is a good brutal test, I've been using it
quite a lot this whole time to evaluate the feature and come up with
the size proposals. The compile will go a lot faster with swap-on-zram
than with heavy swap-on-drive. But it's important in this case to get
the -j option correct for your actual resources. In my case it's 8M
RAM and 8 cores. And the default means 10 jobs, and eventually around
midway into the compile, it wants ~18-20GiB for all the jobs that have
spawned. This fails for me whether swap-on-zram or swap-on-disk, but
fails much faster with the combination of zram *and* earlyoom.
earlyoom is enabled by default in Fedora Workstation 32.


>  > [https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to
>  > discover edge cases, and tweak the default configuration if necessary
>  > to establish a good one-size-fits all approach.
>
>  The developer usage and average (office) user usage are very different.
>  I'm afraid you cannot find any number, which will fit to all. 
I'm reasonably confident sane defaults can be found. This doesn't mean
it's perfect for all workloads. Users right now pretty much accept the
one size fits all swap-on-disk and they never change it because it's a
pain to do that. In the zram case, it's easy to make changes and
optimize.


-- 
Chris Murphy

[Chris Murphy]

On Fri, Jun 5, 2020 at 1:25 AM Frantisek Zatloukal <fzatlouk(a)redhat.com&gt; wrote:

>  I believe having zram as a high priority swap and then normal swap
> with lower priority to be used when zram gets filled up might be an option too (I am not
> saying we should go that route, just mentioning it's a possibility). 
That is the plan, otherwise the swap-on-zram device probably never
gets used. And then its overhead, which is small but not zero, is just
a waste.


-- 
Chris Murphy

[Igor Raits]

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

On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote:
>  Ben Cotton wrote:
>  > Swap is useful, except when it's slow. zram is a RAM drive that
>  > uses
>  > compression. Create a swap-on-zram during start-up. And no longer
>  > use
>  > swap partitions by default.
>  > 
>  > == Owner ==
>  > * Name: [[User:chrismurphy| Chris Murphy]]
>  > * Email: chrismurphy(a)fedoraproject.org
>  
>  I do not think it is safe to assume that zram is sufficient to
>  completely 
>  replace disk swap. We do not know how much RAM is actually available
>  on all 
>  users' machines, and the compressibility of RAM contents depends on
>  the 
>  individual user's workloads. 
The change says it will use 50% of user’s RAM size, but not more than
4G. I did not have chance to test how compression ratio depends on
workloads, but I believew that it will be far more better than 1:1.

Probably there should be some presets in Anaconda with "profiles" that
may default to different swap / zram configurations. But I think as
long as typical use-cases of users are covered (that's how I understand
these settings were chosen), it seems to be better than status quo.

>  So, I am opposed to this change as is.
>  
>  > # Install systemd rust-zram-generator† package. This does not
>  > enable
>  > swap-on-zram, it only makes the generator available.
>  
>  Also -1 to adding something to the core system that is written in a
>  language 
>  for which we do not even have dynamic linking support. Or even real
>  static 
>  linking support, as opposed to packaging libraries as source code. 
This is not fair. It is a programming language that is safer than C and
is already used by some projects that we ship. rpm-ostree, firefox,
librsvg2 and others.

>          Kevin Kofler
>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z+wkACgkQEV1auJxc
> Hh6TxRAAscjHaFs/BWxFAy2bwBeSjO+zJ8s2ZxjULiA8iyUmHooDX9JeRaL6i3/u
> hNEavH6+6uvl9NsOw/YkCoCCbZ8SlgU9rbXi9kbaVf15MdS4ROVJbTTuNzbSY6gB
> kzZEtjQRNmG3PKR8khxRbM2LJX4GzMUV5ZuWQfLnv0BsIouHo4wArZPLo6IrSVXv
> RIwkGmblRq+q9qHjxAeohvosiL3UbSKq0Rch1L+t6jf6Fn92dAtKdRgm+sYr4Dfq
> d5FvI/tCCc4qbOLCa6pNGGZ/KOzl/qExRbXieVgOU1ZdxZZlLctIV3NwNUPLSQX2
> Zq1DVHeajCdA69KNwO7F6uJhX/LYOg6/Ovng8em1yC30U4HzF0Sxj+cIpm4wMOVR
> eAVF90yKK/1F2UQ0FhN0q6SDHNRztG0xPNKHnp+nuelQzpv0zN6pfNX4pvh0dOdD
> R+39XHx1/93hJfg+4uNNBX+pJeaZCFtWjr62BNTcmFBliyAVGuAB0pu4a8EhQdGz
> G9bE3UbmNRfPl5yxNpqM5gXaDlDhKoY/JRwDh6iXGu4PC9OKeWFZxm7+kh4pX+/J
> +1KeIER8soWem/uOL5BzXydjckbSF67zIOlmRN1EyZmF9/+latvTo6tp+PJ3bzt5
> ORDwcLsY4a9P6nNYUkm5rgAT0atN1k5ev4McOIqduhNesER7ck4=
> =Dg2z
> -----END PGP SIGNATURE-----

[Chris Murphy]

On Fri, Jun 5, 2020 at 1:33 AM Igor Raits
<ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  > == Upgrade/compatibility impact ==
>  >
>  > Add Supplements:fedora-release-common to zram-generator to pull it in
>  > on upgrades.
>
>  I would do it other way around just to keep logic sane. 
Hmmm.


>  > Existing systems without swap will have swap-on-zram enabled.
>  >
>  > Existing systems with swap-on-drive, will also have swap-on-zram
>  > enabled (two swap devices), with higher priority for the zram device.
>  > Existing swap-on-drive will not be removed.
>
>  It would be nice to see this in action, what kind of issues this might
>  bring. 
A future feature might be zswap for this case. I've done a lot of
testing with that too but I think it needs some synthetic or contrived
cases to expose the hypothetically better LRU basis efficiency for
what to evict from the cache to the swap-on-disk device. But making it
easier for people to do these experiments with real workloads is a big
part of the feature, while keeping the defaults conservative for
starters.


>  I would appreciate here how to get to the state from swap-on-disk
>  (default workstation) to the new swap-on-zram (new default
>  workstation). So that people can see better how they would be affected
>  by this change. 
Good point. The feature for priority is not yet in zram-generator. A
work around is to swapoff /dev/zram0 and then swapon -p 3000
/dev/zram0. Now it has higher priority than swap-on-disk.




-- 
Chris Murphy

[Igor Raits]

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

On Fri, 2020-06-05 at 02:03 -0600, Chris Murphy wrote:
>  On Fri, Jun 5, 2020 at 1:33 AM Igor Raits
>  <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  > 
>  > > == Upgrade/compatibility impact ==
>  > > 
>  > > Add Supplements:fedora-release-common to zram-generator to pull
>  > > it in
>  > > on upgrades.
>  > 
>  > I would do it other way around just to keep logic sane.
>  
>  Hmmm. 
The fedora-release package is a "dummy" one, so there is no reason to
"Supplement" it because it is meaningless, but having it other way
around should be better.

>  
>  > 
>  > > Existing systems without swap will have swap-on-zram enabled.
>  > > 
>  > > Existing systems with swap-on-drive, will also have swap-on-zram
>  > > enabled (two swap devices), with higher priority for the zram
>  > > device.
>  > > Existing swap-on-drive will not be removed.
>  > 
>  > It would be nice to see this in action, what kind of issues this
>  > might
>  > bring.
>  
>  A future feature might be zswap for this case. I've done a lot of
>  testing with that too but I think it needs some synthetic or
>  contrived
>  cases to expose the hypothetically better LRU basis efficiency for
>  what to evict from the cache to the swap-on-disk device. But making
>  it
>  easier for people to do these experiments with real workloads is a
>  big
>  part of the feature, while keeping the defaults conservative for
>  starters.
>  
>  
>  > I would appreciate here how to get to the state from swap-on-disk
>  > (default workstation) to the new swap-on-zram (new default
>  > workstation). So that people can see better how they would be
>  > affected
>  > by this change.
>  
>  Good point. The feature for priority is not yet in zram-generator. A
>  work around is to swapoff /dev/zram0 and then swapon -p 3000
>  /dev/zram0. Now it has higher priority than swap-on-disk. 
I mean to convert existing installation to the new way that would be
installed from scratch, so have only zram and not have physical swap. I
understand that we do not want to automagically remove physical swap on
upgrade, but it would be nice to have howto that describes how to
enable zram together with removal of physical swap.

>  
>  
>  
>  -- 
>  Chris Murphy
>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Z/5gACgkQEV1auJxc
> Hh4wuxAAqGsG3tdWdSEQl3VxEzL474KvKZMWjJ4JMRt4LPjvvr6U5zexeL+V8iPj
> vKRPfV6DGZy/cKmn4LlKK/t+C4ITYyTCK2x96CsL0qtNKC1xp5UoxBvgr/dKj4ao
> bBHjzQqubjW21FedOHfblECx8uGL+1taKENb2oNr+s0AOVAxXW9U88/GSf/bwJbC
> 8QDqeEuW4Ea3Lmr/3z19QchCH7EzQJqgpOrkPw5Q1b/aLcTdcqeO9jKOzBMUxyJe
> czuOGkFELcKRECJwvPTF7nkXBG48kIVGe/JJ57l66+RzF6djd4//IW58Qtj9aI8q
> HjN/LwdsgxcknSeF/tCXDkTk/STYLJ7C6WqdHJGEf+nHId54GrkYyXjRgIXFuy+P
> gM3TPtX8RJ5dFBpmOubGgMeQBos6doFWxKGCnER7s2qDBUOwv+EZUSx6IP7PdYA/
> C9NF4vBb/qhhbR3zfBcdPYfbEmA+CUxabop81mmOIv1Q/xs0xsIkbMqg/nO0ya4q
> K2VmFmR3SMBVcXGWiY7G6MHk1rGIn1TWOtAlVYPgUoFS55e/ES5LG8SvCw2Vf7jP
> IBBEqoiphchhCUR7h/V0k4nT5TLXsdIkZHxKZVccHqGdUY7sPea09eX2Pv+jtKv4
> OqqDEKD+XO+cXh5CHRZeLnJrKJfNkdRJ9Ur5pBq+/b4ZG5tjjH4=
> =ocnt
> -----END PGP SIGNATURE-----

[Igor Raits]

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

On Fri, 2020-06-05 at 10:17 +0200, Igor Raits wrote:
>  On Fri, 2020-06-05 at 02:03 -0600, Chris Murphy wrote:
>  > On Fri, Jun 5, 2020 at 1:33 AM Igor Raits
>  > <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  > > 
>  > > > == Upgrade/compatibility impact ==
>  > > > 
>  > > > Add Supplements:fedora-release-common to zram-generator to pull
>  > > > it in
>  > > > on upgrades.
>  > > 
>  > > I would do it other way around just to keep logic sane.
>  > 
>  > Hmmm.
>  
>  The fedora-release package is a "dummy" one, so there is no reason to
>  "Supplement" it because it is meaningless, but having it other way
>  around should be better.
>  
>  > 
>  > > 
>  > > > Existing systems without swap will have swap-on-zram enabled.
>  > > > 
>  > > > Existing systems with swap-on-drive, will also have swap-on-
>  > > > zram
>  > > > enabled (two swap devices), with higher priority for the zram
>  > > > device.
>  > > > Existing swap-on-drive will not be removed.
>  > > 
>  > > It would be nice to see this in action, what kind of issues this
>  > > might
>  > > bring.
>  > 
>  > A future feature might be zswap for this case. I've done a lot of
>  > testing with that too but I think it needs some synthetic or
>  > contrived
>  > cases to expose the hypothetically better LRU basis efficiency for
>  > what to evict from the cache to the swap-on-disk device. But making
>  > it
>  > easier for people to do these experiments with real workloads is a
>  > big
>  > part of the feature, while keeping the defaults conservative for
>  > starters.
>  > 
>  > 
>  > > I would appreciate here how to get to the state from swap-on-disk
>  > > (default workstation) to the new swap-on-zram (new default
>  > > workstation). So that people can see better how they would be
>  > > affected
>  > > by this change.
>  > 
>  > Good point. The feature for priority is not yet in zram-generator.
>  > A
>  > work around is to swapoff /dev/zram0 and then swapon -p 3000
>  > /dev/zram0. Now it has higher priority than swap-on-disk.
>  
>  I mean to convert existing installation to the new way that would be
>  installed from scratch, so have only zram and not have physical swap.
>  I
>  understand that we do not want to automagically remove physical swap
>  on
>  upgrade, but it would be nice to have howto that describes how to
>  enable zram together with removal of physical swap. 
That should also include how to modify resume= parameter and regenerate
BLS / grub configuration.

>  > 
>  > 
>  > 
>  > -- 
>  > Chris Murphy
>  > _______________________________________________
>  > 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/[e-mail] 
-
-- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aAKsACgkQEV1auJxc
> Hh73qA//eWFYtpO8V8Ro3TuJemzRRYs8LHMFUfzSM/adiEWhaAJdd02i1Dy0tqmm
> xJXgV8GazWPuOpiOoixhhNd4ekk/85JB+Eo6AQGtXDcTKkVl3SP9QSt2JnzL+6wR
> i3lCYDsgTHSmZdPFJVhHtbad6eTgZYRGQz92PacpTin6Z5N6laZEv/TykgVLLb97
> Z8pfqw3rdiW5IFwoCqkPUrTvdioyKaqchc6N67T3nMo68cwocA9Yre1iFOKcCJlG
> 4+cGjSS0oCqWcHOdkM06pJS8Uwv4Kq5luG/XofD0L0TNkvxbAkP/VXtV6an2CBTy
> EAtv3CffvkmUjW1G5i04Z1BZ+dGDeQ7NPTFrRhhnTU8H4VGEr0WGIGhlWEM+HF1r
> 29c+ymZlHiGEwi0eEHRhNwqHbH6qS3bNuEl8P74e79uoB6gTivuQ3Vk724r/NmZI
> WoUb3QdZPyT32r9bzcDKqv90nLQLOWxpF89YWGlTPoKNpccQl+8sHu88zbKADFQC
> oz0vNSODM403f5giiaxSRLVlV2q6szR7hXljrZ933ySRtxGkAlhEIPTZDdwPe9Wy
> zVfN8Ky4F+VVAwT2EErdpBRA9LifHVRxHklzwTgXx8AUxN0WbbhBAzGbXtJqM5tL
> 3KCTK+lRzztudtB3Xzj9uGATeuBPEaX+pIIqk7cNQ3G9K91seGc=
> =05Jh
> -----END PGP SIGNATURE-----

[Kamil Paral]

On Thu, Jun 4, 2020 at 10:32 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>
>  == Summary ==
>
>  Swap is useful, except when it's slow. zram is a RAM drive that uses
>  compression. Create a swap-on-zram during start-up. And no longer use
>  swap partitions by default.
>  
I haven't tested it personally on my system yet, but I've read the proposal
carefully (it's very well described, thank you!) and it sounds like a good
change, so thumbs up at the moment. This might offer much better system
interactivity under heavy RAM workloads compared to alternative OSes which
don't use RAM compression (e.g. Windows). I like that. If /dev/zram0 really
dynamically scales up and down and occupies no real memory when swap is not
used, I can't see any disadvantages there. The only thing is that it will
prevent using hibernation by default, but that's a whole different topic
that is dealt with separately and I understand it's sadly a very broken
feature at the moment anyway.

[Vitaly Zaitsev]

On 04.06.2020 22:30, Ben Cotton wrote:
>  Swap is useful, except when it's slow. zram is a RAM drive that
> uses
>  compression. Create a swap-on-zram during start-up. And no longer use
>  swap partitions by default. 
I'm strongly against this, because zram will replace disk swap and
disable hibernation, which is very useful on laptops.

I suggest zswap instead (with zswap-cli[1] implementation).

[1]: https://github.com/xvitaly/zswap-cli

-- 
Sincerely,
  Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 05.06.2020 09:24, Frantisek Zatloukal wrote:
>  I am +1 for this change, I don't have any numbers but from
> day-to-day
>  usage, both my systems seem far more responsive when swapping to zram
>  instead of swap. 
But it will cause a huge memory fragmentation and significantly decrease
overall performance.

-- 
Sincerely,
  Vitaly Zaitsev (vitaly(a)easycoding.org)

[Igor Raits]

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

On Fri, 2020-06-05 at 12:34 +0200, Vitaly Zaitsev via devel wrote:
>  On 04.06.2020 22:30, Ben Cotton wrote:
>  > Swap is useful, except when it's slow. zram is a RAM drive that
>  > uses
>  > compression. Create a swap-on-zram during start-up. And no longer
>  > use
>  > swap partitions by default.
>  
>  I'm strongly against this, because zram will replace disk swap and
>  disable hibernation, which is very useful on laptops. 
It does not work in some cases even today anyway. For those who still
want to use hibernation, whether it is some checkbox in anaconda or
magic that guesses if that actually works on your machine (whether it
is laptop and Secure Boot is disabled).

>  I suggest zswap instead (with zswap-cli[1] implementation).
>  
>  [1]: https://github.com/xvitaly/zswap-cli
>  
>  -- 
>  Sincerely,
>    Vitaly Zaitsev (vitaly(a)easycoding.org)
>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aI2kACgkQEV1auJxc
> Hh7qdhAAmnCP6a7ZPtTi/P+KFvmn8CeqtjAJFDapRe5M5cGLbam4gDaQD7ZnkeiD
> p2Fo5C3W/QkhCv+4X7caXEtLJjWlFQWEUPlnZraI7lOLXGIfbsGJHzIKkycSWjZb
> sJb/ql7te3n+H7KecYC9elZFJhh5Fz5Xlbgv7Pig1n3d+jqa6aHW22+8wzmX0eTI
> HaBeXuvu4a0ICL49+QZooWJIdb4hVdqyJOoNX93QtkgP4DdMJrmKPQaXuzawn8VA
> vy5yL5IvCTj4DcDaFIZ3Dc0nidu+fTzq6GCKQg55zelqXqsXax0+S1fIABbacXlv
> Q2ljmHaaz/ZEohsNwfXZ0mAWVMmyldeMiJrLiFd3wVRLL3XIxSUff7+bGEVZByhw
> QQLZ1nmcGEG3X0e4Vdz3xwuhulADMDqeKQ50ANdJt+a8XzaslR2IXdx9wJtx5dK9
> SM3MF6lil7fQAyEF0zumAvUAdf/EztXaype9WsjUOi5It1wuhgKSsaV8F/u7+xFU
> b0Kzlo/AD9AS/tqg0sOfQ4kfHgEZg7X6xgwELzYav/fdBq/4cQLQzkHziIPGsUu+
> wMQM9fvKUsvN7LVWCUMizifoDtqxtpnOkGmvDaISMPkdLGNI25KDvcAzNZKxVICg
> 0ULVTE439MRVEeB3cVLWRLEsPIRUN9o0HgxsZ5ZgJdGPZTXGkDY=
> =+rta
> -----END PGP SIGNATURE-----

[Vitaly Zaitsev]

On 05.06.2020 12:50, Igor Raits wrote:
>  It does not work in some cases even today anyway. 
Okay, then the second point - zram will will cause a huge memory
fragmentation and significantly decrease overall performance.

-- 
Sincerely,
  Vitaly Zaitsev (vitaly(a)easycoding.org)

[David Schwörer]

On 6/5/20 1:23 PM, Vitaly Zaitsev via devel wrote:
>  On 05.06.2020 12:50, Igor Raits wrote:
> > It does not work in some cases even today anyway.
>  
>  Okay, then the second point - zram will will cause a huge memory
>  fragmentation and significantly decrease overall performance. 
If you say this is significant, how did you measure?
And do you have more detailed results?

Or is this speculation?

[Michael Catanzaro]

On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy <lists(a)colorremedies.com&gt; 
wrote:
>  That is the plan, otherwise the swap-on-zram device probably never
>  gets used. And then its overhead, which is small but not zero, is just
>  a waste. 
I thought the plan was to get rid of the disk-based swap partition, 
since it has an unacceptable impact on system responsiveness?

[Peter Robinson]

>  On 05.06.2020 12:50, Igor Raits wrote:
>  > It does not work in some cases even today anyway.
>
>  Okay, then the second point - zram will will cause a huge memory
>  fragmentation and significantly decrease overall performance. 
Have you got proof of that and can provide figures? Having been
running it on Arm and IoT by default for a few releases now it
certainly doesn't cause fragmentation, it's allocated early in the
boot process so it's one single block. I also run zram on my laptop
and it's generally faster as when it has to hit swap that's backed by
RAM and is an order of magnitude faster, even with dealing with
compression, than hitting my NVME SSD.

[Igor Raits]

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

On Fri, 2020-06-05 at 07:42 -0500, Michael Catanzaro wrote:
>  On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
>  <lists(a)colorremedies.com&gt; 
>  wrote:
>  > That is the plan, otherwise the swap-on-zram device probably never
>  > gets used. And then its overhead, which is small but not zero, is
>  > just
>  > a waste.
>  
>  I thought the plan was to get rid of the disk-based swap partition, 
>  since it has an unacceptable impact on system responsiveness? 
If I understand correctly, this is only for upgradepath. The clean
install should have only zram, but I might be wrong.

>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7aRK8ACgkQEV1auJxc
> Hh7pFA//XJ1FjBF8d3GrEBFIZ+ML1tR3Nr5hbo2cFD6p0dokYocrH8Xz2V9GvDla
> MAuKSNBXa4AohzaQ1w6JHSNJVlQya9FlqWk61+I8uWA+y9/vJGc7mV7AaJKzbEsa
> 4DvGEFFgpwnWcWl0K0W4Y6JZrw0o5mpZZrXumF0I86tOb/w72Bg5DZBvUjGRk1i9
> uZvupNNiFdMaBOwz/26v8r/0qzZG1xmEv+YXw+wDnXXX1hAENl0/ZxlEc23IVWt4
> 8fvpiwOTrex9CKvFVIDFsAW3k9Cjn+gYUZF3K23toZPN4dPlUle9UpVezX0YrtdD
> pBeX4zzt68N8ofoz/uQzHKAuxvQ/EtO1lKP1M7SXylev5ZPTWZfbCWfjQc6/cBmd
> 2wNsKastLVnLGEPipFu4phYLIs0eqRGqzK3wuia7IRd0abLV0TPq98F2iGbME1OC
> hixrJtgP8zZoE7d0SPgdzy+7ne0k8AXsrwemOnloIcWMfwl8yezWutQzrHJ0A+Va
> wFFRyASld7KZ8BY8lbWmCxG4pWoUeMX0FRg0bW/p14Xa8Vcom/THJw+Q/D7F4su0
> 7nRihJpcx597xhfwaz88RAG4KF1IveIK659p9jKuEc6SAtJOAnLH63gUFObvGaOt
> wp5RBHGBMnbAqV7cR0LYrEzktQf8hVOF35kNtc8ozLt5ib0Em/E=
> =58Nc
> -----END PGP SIGNATURE-----

[Richard W.M. Jones]

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&gt;
> 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?

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

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

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

[Igor Raits]

-----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&gt;
>  > 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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----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-----

[John M. Harris Jr]

On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote:
>  Ben Cotton wrote:
>  
>  > Swap is useful, except when it's slow. zram is a RAM drive that uses
>  > compression. Create a swap-on-zram during start-up. And no longer use
>  > swap partitions by default.
>  > 
>  > == Owner ==
>  > * Name: [[User:chrismurphy| Chris Murphy]]
>  > * Email: chrismurphy(a)fedoraproject.org
>  
>  
>  I do not think it is safe to assume that zram is sufficient to completely 
>  replace disk swap. We do not know how much RAM is actually available on all
>  users' machines, and the compressibility of RAM contents depends on the
>  individual user's workloads.
>  
>  So, I am opposed to this change as is.
>  
>  
>  > # Install systemd rust-zram-generator† package. This does not enable
>  > swap-on-zram, it only makes the generator available.
>  
>  
>  Also -1 to adding something to the core system that is written in a language
>  for which we do not even have dynamic linking support. Or even real
>  static linking support, as opposed to packaging libraries as source code. 
>          Kevin Kofler 
Agreed. Besides, GNOME already has this enabled, right? It's definitely not 
right for servers, as I brought up the last time this was thrown around. 

-- 
John M. Harris, Jr.

[Chris Murphy]

On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 04.06.2020 22:30, Ben Cotton wrote:
>  > Swap is useful, except when it's slow. zram is a RAM drive that uses
>  > compression. Create a swap-on-zram during start-up. And no longer use
>  > swap partitions by default.
>
>  I'm strongly against this, because zram will replace disk swap and
>  disable hibernation, which is very useful on laptops. 
Already discussed in the 'support hibernation' thread.

Most laptops today have UEFI Secure Boot enabled by default and
therefore hibernation isn't possible. And even when the laptop doesn't
have Secure Boot enabled, there's a forest of bugs. It works for some
people and not others. It was working for me on one laptop in
February, consistently doesn't work now and I haven't gotten a reply
yet from upstream about the problem.

>  I suggest zswap instead (with zswap-cli[1] implementation).
>
>  [1]: https://github.com/xvitaly/zswap-cli 
I am a fan of zswap too, but it needs deconfliction logic with
swap-on-zram. The generator would need to come after the
fstab-generator, so that it could know if there is a swap-on-drive
partition. From that it could do swap-on-zram if there is no
swap-on-drive. And setup zswap if there is (instead of two swap
devices). The kernel has support for 32 swap devices, since almost
forever.

I've done enough testing with zswap in all the same conditions I've
used zram, that I'm confident this can be implemented with this
feature in the F33 time frame. But someone needs to help out with the
zram-generator code to teach it how to use zswap. There is a sysfs
interface to do it so that's pretty straightforward and I think that's
how zram-generator does things now for zram, it's not yet using
zramctl for setup.

I can plan to have supplementary tests for zswap on the test day.
Hypothetically zswap is a bit smarter because of the LRU basis it uses
to decide what to toss out of the memory cache to the swap-on-drive.
Whereas two swaps where /dev/zram0 has higher priority, gets favored
until it's full, then uses /dev/swapondrive. But in my testing I
haven't been able to prove zswap is better.

-- 
Chris Murphy

[John M. Harris Jr]

On Friday, June 5, 2020 3:20:30 AM MST Kamil Paral wrote:
>  On Thu, Jun 4, 2020 at 10:32 PM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  > https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>  > 
>  > == Summary ==
>  > 
>  > Swap is useful, except when it's slow. zram is a RAM drive that uses
>  > compression. Create a swap-on-zram during start-up. And no longer use
>  > swap partitions by default.
>  
>  I haven't tested it personally on my system yet, but I've read the proposal
>  carefully (it's very well described, thank you!) and it sounds like a good
>  change, so thumbs up at the moment. This might offer much better system
>  interactivity under heavy RAM workloads compared to alternative OSes which
>  don't use RAM compression (e.g. Windows). I like that. If /dev/zram0 really
>  dynamically scales up and down and occupies no real memory when swap is not
>  used, I can't see any disadvantages there. The only thing is that it will
>  prevent using hibernation by default, but that's a whole different topic
>  that is dealt with separately and I understand it's sadly a very broken
>  feature at the moment anyway. 
At the moment, it seems that hibernation is only broken on systems with Secure 
Boot enabled, because of a kernel lockdown anti-feature.


-- 
John M. Harris, Jr.

[John M. Harris Jr]

On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
>  On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  
>  >
>  >
>  > On 04.06.2020 22:30, Ben Cotton wrote:
>  > 
>  > > Swap is useful, except when it's slow. zram is a RAM drive that uses
>  > > compression. Create a swap-on-zram during start-up. And no longer use
>  > > swap partitions by default.
>  >
>  >
>  >
>  > I'm strongly against this, because zram will replace disk swap and
>  > disable hibernation, which is very useful on laptops.
>  
>  
>  Already discussed in the 'support hibernation' thread.
>  
>  Most laptops today have UEFI Secure Boot enabled by default and
>  therefore hibernation isn't possible. And even when the laptop doesn't
>  have Secure Boot enabled, there's a forest of bugs. It works for some
>  people and not others. It was working for me on one laptop in
>  February, consistently doesn't work now and I haven't gotten a reply
>  yet from upstream about the problem. 
It may be true that most laptops have "Secure Boot" enabled, but not those 
running Fedora. We don't have numbers to support that claim, and most devices 
require "Secure Boot" to be disabled,  or to have the mode changed so that it 
accepts new keys, to install Fedora.

-- 
John M. Harris, Jr.

[Neal Gompa]

On Fri, Jun 5, 2020 at 2:09 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
>  > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
>  > <devel(a)lists.fedoraproject.org&gt; wrote:
>  >
>  > >
>  > >
>  > > On 04.06.2020 22:30, Ben Cotton wrote:
>  > >
>  > > > Swap is useful, except when it's slow. zram is a RAM drive that uses
>  > > > compression. Create a swap-on-zram during start-up. And no longer use
>  > > > swap partitions by default.
>  > >
>  > >
>  > >
>  > > I'm strongly against this, because zram will replace disk swap and
>  > > disable hibernation, which is very useful on laptops.
>  >
>  >
>  > Already discussed in the 'support hibernation' thread.
>  >
>  > Most laptops today have UEFI Secure Boot enabled by default and
>  > therefore hibernation isn't possible. And even when the laptop doesn't
>  > have Secure Boot enabled, there's a forest of bugs. It works for some
>  > people and not others. It was working for me on one laptop in
>  > February, consistently doesn't work now and I haven't gotten a reply
>  > yet from upstream about the problem.
>
>  It may be true that most laptops have "Secure Boot" enabled, but not those
>  running Fedora. We don't have numbers to support that claim, and most devices
>  require "Secure Boot" to be disabled,  or to have the mode changed so that it
>  accepts new keys, to install Fedora.
>  
This is not true. Fedora installs perfectly fine on Secure
Boot-enabled systems without any change to the enrolled keys. Our shim
package is signed by a key that has been required to be trusted for
virtually all x86 PCs for the past several years.

The *only* case where Secure Boot must be disabled for the proper
functioning of a PC today is if you use the NVIDIA proprietary
drivers, because nobody is helping RPM Fusion set up a mechanism to
sign their driver and load the key into the kernel for trust.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[John M. Harris Jr]

On Friday, June 5, 2020 11:12:10 AM MST Neal Gompa wrote:
>  On Fri, Jun 5, 2020 at 2:09 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
>  > 
>  > > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
>  > > <devel(a)lists.fedoraproject.org&gt; wrote:
>  > >
>  > >
>  > >
>  > > >
>  > > >
>  > > >
>  > > > On 04.06.2020 22:30, Ben Cotton wrote:
>  > > >
>  > > >
>  > > >
>  > > > > Swap is useful, except when it's slow. zram is a RAM drive that
>  > > > > uses
>  > > > > compression. Create a swap-on-zram during start-up. And no longer
>  > > > > use
>  > > > > swap partitions by default.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > I'm strongly against this, because zram will replace disk swap and
>  > > > disable hibernation, which is very useful on laptops.
>  > >
>  > >
>  > >
>  > >
>  > > Already discussed in the 'support hibernation' thread.
>  > >
>  > >
>  > >
>  > > Most laptops today have UEFI Secure Boot enabled by default and
>  > > therefore hibernation isn't possible. And even when the laptop doesn't
>  > > have Secure Boot enabled, there's a forest of bugs. It works for some
>  > > people and not others. It was working for me on one laptop in
>  > > February, consistently doesn't work now and I haven't gotten a reply
>  > > yet from upstream about the problem.
>  >
>  >
>  >
>  > It may be true that most laptops have "Secure Boot" enabled, but not
>  > those
>  > running Fedora. We don't have numbers to support that claim, and most
>  > devices require "Secure Boot" to be disabled,  or to have the mode
>  > changed so that it accepts new keys, to install Fedora.
>  >
>  >
>  
>  
>  This is not true. Fedora installs perfectly fine on Secure
>  Boot-enabled systems without any change to the enrolled keys. Our shim
>  package is signed by a key that has been required to be trusted for
>  virtually all x86 PCs for the past several years.
>  
>  The *only* case where Secure Boot must be disabled for the proper
>  functioning of a PC today is if you use the NVIDIA proprietary
>  drivers, because nobody is helping RPM Fusion set up a mechanism to
>  sign their driver and load the key into the kernel for trust. 
Most of the "Secure Boot" hardware I've gotten my hands on have been early 
generations, up to some produced in 2015. I've had to change the mode to 
"deployment" on some HP ProDesk systems in order to get it to install Fedora, 
for example. I can't speak for the most recent generations, but I remain 
skeptical due to the "lockdown" functionality breaking everything.

Other times you'd need to do so are when you'd like hibernation support, any 
out of tree modules such as ZFS, kexec, hot patching.. 

-- 
John M. Harris, Jr.

[Igor Raits]

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

On Fri, 2020-06-05 at 11:08 -0700, John M. Harris Jr wrote:
>  On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
>  > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
>  > <devel(a)lists.fedoraproject.org&gt; wrote:
>  > 
>  > > 
>  > > 
>  > > On 04.06.2020 22:30, Ben Cotton wrote:
>  > > 
>  > > > Swap is useful, except when it's slow. zram is a RAM drive that
>  > > > uses
>  > > > compression. Create a swap-on-zram during start-up. And no
>  > > > longer use
>  > > > swap partitions by default.
>  > > 
>  > > 
>  > > 
>  > > I'm strongly against this, because zram will replace disk swap
>  > > and
>  > > disable hibernation, which is very useful on laptops.
>  > 
>  > 
>  > Already discussed in the 'support hibernation' thread.
>  > 
>  > Most laptops today have UEFI Secure Boot enabled by default and
>  > therefore hibernation isn't possible. And even when the laptop
>  > doesn't
>  > have Secure Boot enabled, there's a forest of bugs. It works for
>  > some
>  > people and not others. It was working for me on one laptop in
>  > February, consistently doesn't work now and I haven't gotten a
>  > reply
>  > yet from upstream about the problem.
>  
>  It may be true that most laptops have "Secure Boot" enabled, but not
>  those 
>  running Fedora. We don't have numbers to support that claim, and most
>  devices 
>  require "Secure Boot" to be disabled,  or to have the mode changed so
>  that it 
>  accepts new keys, to install Fedora. 
They don't require disablement. Fedora shim loader is signed by
Microsoft that means it is installed in most (all?) laptops.

>  -- 
>  John M. Harris, Jr.
>  
>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7ajmAACgkQEV1auJxc
> Hh7Nzg//UYaFPMpfVM6CwQ9wlfAAUrz444Lbvn6CrutshqIDylXsBigD6uAC0mAP
> K9Z1U46FPkBjQRBIVuckAS5kK4ZAkg43QeUNAZJwlqDTJigdvwHDGpgGcRTWwA/f
> cg2bzcTxvZ+bBpHo6R8yZEzjMydavvZYMBFOnXcfkUUhDSsyctou8BDNo43K/wOD
> iexpV0tYgz8fq14aAvJrI2/0jZbvW3Mi4H1bHrdC0/7Odtghuo3Erp+H5IF7+A+9
> QdlbOSJVJUm/8aKwpzeHgkAqY3wSZtg1AXhJp+OEUDkt9MzpvjQw/Zpny8B5+G68
> /+chMP/Fq7jIbLoqNKyzNpgVUiYNm+Yl2J3ro0nQbXzG0Bo7VH3+SVso5kE1pMEC
> do7XGxWziXEGfQcRZVfdoH6GDzE4yO0TiSFmd3i2GrH3BeMrDa6KboBvPBHHSs89
> iSeUgce8Can+IHjPkv8Kb4UoMVl9pEwNOQe4WJIHy4TNVQKq1TJm8Z/nU04zehsZ
> lhVVhIMyP+qUF5/RieYqHxM1OkkDMA2z8dohHFsP7u+YhBiyVu6zcSl4wfD3Y3CX
> 2tpbTAMO6hGJ3HwqQeVgdJC+Jy3gdrAKmpFtAioKa8cdx87UaszB3Sov+H7tD2JC
> 6X7s7Q4Cm5ROL2FfdGEzXcPjQ4FGvdiG5WRtKau9yGO8Avf1OTs=
> =nTKL
> -----END PGP SIGNATURE-----

[Chris Murphy]

On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy <lists(a)colorremedies.com&gt;
>  wrote:
>  > That is the plan, otherwise the swap-on-zram device probably never
>  > gets used. And then its overhead, which is small but not zero, is just
>  > a waste.
>
>  I thought the plan was to get rid of the disk-based swap partition,
>  since it has an unacceptable impact on system responsiveness? 
Default new installations, yes. No disk-based swap partition.

For upgrades, there's no mechanism to remove an existing
swap-on-drive. And the installer will still permit swap-on-drive being
added in custom partitioning. Both of these paths results in two swap
devices.

We could ask Anaconda, if a custom installation creates swap-on-disk,
to remove /etc/systemd/zram-generator.conf. And in that case, users
will not get swap-on-zram. And we could also forgo the change being
applied on upgrades.


-- 
Chris Murphy

[Chris Murphy]

On Fri, Jun 5, 2020 at 7:09 AM Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  > On 05.06.2020 12:50, Igor Raits wrote:
>  > > It does not work in some cases even today anyway.
>  >
>  > Okay, then the second point - zram will will cause a huge memory
>  > fragmentation and significantly decrease overall performance.
>
>  Have you got proof of that and can provide figures? Having been
>  running it on Arm and IoT by default for a few releases now it
>  certainly doesn't cause fragmentation, it's allocated early in the
>  boot process so it's one single block. I also run zram on my laptop
>  and it's generally faster as when it has to hit swap that's backed by
>  RAM and is an order of magnitude faster, even with dealing with
>  compression, than hitting my NVME SSD. 
With one exception, I agree with all of this including better swap
performance than on NVMe (~1500M/s).

/dev/zram0 is definitely not preallocated

$ cat /sys/block/zram0/mm_stat
    4096       74    12288        0    12288        0        0        0
$ zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.9G   4K   74B   12K       8 [SWAP]
]$

This 4G /dev/zram0 device isn't being used by swap right now.

From the kernel documentation:

mem_used_total   the amount of memory allocated for this disk. This
                  includes allocator fragmentation and metadata overhead,
                  allocated for this disk. So, allocator space efficiency
                  can be calculated using compr_data_size and this statistic.




-- 
Chris Murphy

[Chris Murphy]

On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote: 
>  > Also -1 to adding something to the core system that is written
> in a language
>  > for which we do not even have dynamic linking support. Or even real
>  > static linking support, as opposed to packaging libraries as source code.
>  >         Kevin Kofler
>
>  Agreed. Besides, GNOME already has this enabled, right? It's definitely not
>  right for servers, as I brought up the last time this was thrown around. 
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.


-- 
Chris Murphy

[John M. Harris Jr]

On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
>  On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro
> <mcatanzaro(a)gnome.org&gt;
>  wrote:
>  >
>  >
>  > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy <lists(a)colorremedies.com&gt;
>  > wrote:
>  > 
>  > > That is the plan, otherwise the swap-on-zram device probably never
>  > > gets used. And then its overhead, which is small but not zero, is just
>  > > a waste.
>  >
>  >
>  >
>  > I thought the plan was to get rid of the disk-based swap partition,
>  > since it has an unacceptable impact on system responsiveness?
>  
>  
>  Default new installations, yes. No disk-based swap partition.
>  
>  For upgrades, there's no mechanism to remove an existing
>  swap-on-drive. And the installer will still permit swap-on-drive being
>  added in custom partitioning. Both of these paths results in two swap
>  devices.
>
>  We could ask Anaconda, if a custom installation creates swap-on-disk,
>  to remove /etc/systemd/zram-generator.conf. And in that case, users
>  will not get swap-on-zram. And we could also forgo the change being
>  applied on upgrades. 
It may be best to respect the user's decision, and not add a zram device on 
upgraded systems. This would lead to less unexpected behavior. I'd support 
that, for sure :)

-- 
John M. Harris, Jr.

[Chris Murphy]

On Fri, Jun 5, 2020 at 12:19 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  > The *only* case where Secure Boot must be disabled for the proper
>  > functioning of a PC today is if you use the NVIDIA proprietary
>  > drivers, because nobody is helping RPM Fusion set up a mechanism to
>  > sign their driver and load the key into the kernel for trust.
>
>  Most of the "Secure Boot" hardware I've gotten my hands on have been early
>  generations, up to some produced in 2015. I've had to change the mode to
>  "deployment" on some HP ProDesk systems in order to get it to install Fedora,
>  for example. I can't speak for the most recent generations, but I remain
>  skeptical due to the "lockdown" functionality breaking everything.
>
>  Other times you'd need to do so are when you'd like hibernation support, any
>  out of tree modules such as ZFS, kexec, hot patching.. 
That signing kernels is non-obvious and should get better does not
mean it is good advice to tell people to disable UEFI Secure Boot. I
have used out of tree ZFS in the past with Secure Boot enabled by
signing the modules.


Please move the non zram discussion to another thread. It's respectful
to readers who come to this thread expecting to read about this
subject matter.

-- 
Chris Murphy

[John M. Harris Jr]

On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote:
>  On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote:
>  
>  
>  
>  > > Also -1 to adding something to the core system that is written in a
>  > > language for which we do not even have dynamic linking support. Or
>  > > even real static linking support, as opposed to packaging libraries as
>  > > source code.> > 
>  > >         Kevin Kofler
>  >
>  >
>  >
>  > Agreed. Besides, GNOME already has this enabled, right? It's definitely
>  > not right for servers, as I brought up the last time this was thrown
>  > around.
>  
>  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.

It really seems like this is wrong for most of Fedora, but that individual 
parts, such as Fedora GNOME or IoT, should be left to make the decision for 
themselves, without affecting the rest.

-- 
John M. Harris, Jr.

[Chris Murphy]

On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
>  > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
>  > wrote:
>  > >
>  > >
>  > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy <lists(a)colorremedies.com&gt;
>  > > wrote:
>  > >
>  > > > That is the plan, otherwise the swap-on-zram device probably never
>  > > > gets used. And then its overhead, which is small but not zero, is just
>  > > > a waste.
>  > >
>  > >
>  > >
>  > > I thought the plan was to get rid of the disk-based swap partition,
>  > > since it has an unacceptable impact on system responsiveness?
>  >
>  >
>  > Default new installations, yes. No disk-based swap partition.
>  >
>  > For upgrades, there's no mechanism to remove an existing
>  > swap-on-drive. And the installer will still permit swap-on-drive being
>  > added in custom partitioning. Both of these paths results in two swap
>  > devices.
>  >
>  > We could ask Anaconda, if a custom installation creates swap-on-disk,
>  > to remove /etc/systemd/zram-generator.conf. And in that case, users
>  > will not get swap-on-zram. And we could also forgo the change being
>  > applied on upgrades.
>
>  It may be best to respect the user's decision, and not add a zram device on
>  upgraded systems. This would lead to less unexpected behavior. I'd support
>  that, for sure :) 
Contra argument: It also leads to fragmentation of the user base. Most
users use a distribution because they trust the decisions. And while
it is only a preference, not a policy the Workstation Product
Requirements Document says  "Upgrading the system multiple times
through the upgrade process should give a result that is the same as
an original install of Fedora Workstation."

There is a balancing act here that should be considered because a
large percent of Fedora users upgrade rather than reprovision. It
might even be the majority case.


-- 
Chris Murphy

[Chris Murphy]

On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr <johnmh(a)splentity.com&gt; 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.

>  It really seems like this is wrong for most of Fedora, but that
> individual
>  parts, such as Fedora GNOME or IoT, should be left to make the decision for
>  themselves, without affecting the rest. 
Your opinion is noted. And now you don't have to keep repeating
yourself and swamping the list with extraneous emails that contribute
nothing new, correct? If you have some new insight, that's great.


-- 
Chris Murphy

[John M. Harris Jr]

On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
>  On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
>  > 
>  > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
>  > > wrote:
>  > > 
>  > > >
>  > > >
>  > > >
>  > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
>  > > > <lists(a)colorremedies.com&gt;
>  > > > wrote:
>  > > >
>  > > >
>  > > >
>  > > > > That is the plan, otherwise the swap-on-zram device probably never
>  > > > > gets used. And then its overhead, which is small but not zero, is
>  > > > > just
>  > > > > a waste.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > I thought the plan was to get rid of the disk-based swap partition,
>  > > > since it has an unacceptable impact on system responsiveness?
>  > >
>  > >
>  > >
>  > >
>  > > Default new installations, yes. No disk-based swap partition.
>  > >
>  > >
>  > >
>  > > For upgrades, there's no mechanism to remove an existing
>  > > swap-on-drive. And the installer will still permit swap-on-drive being
>  > > added in custom partitioning. Both of these paths results in two swap
>  > > devices.
>  > >
>  > >
>  > >
>  > > We could ask Anaconda, if a custom installation creates swap-on-disk,
>  > > to remove /etc/systemd/zram-generator.conf. And in that case, users
>  > > will not get swap-on-zram. And we could also forgo the change being
>  > > applied on upgrades.
>  >
>  >
>  >
>  > It may be best to respect the user's decision, and not add a zram device
>  > on upgraded systems. This would lead to less unexpected behavior. I'd
>  > support that, for sure :)
>  
>  
>  Contra argument: It also leads to fragmentation of the user base. Most
>  users use a distribution because they trust the decisions. And while
>  it is only a preference, not a policy the Workstation Product
>  Requirements Document says  "Upgrading the system multiple times
>  through the upgrade process should give a result that is the same as
>  an original install of Fedora Workstation."
>  
>  There is a balancing act here that should be considered because a
>  large percent of Fedora users upgrade rather than reprovision. It
>  might even be the majority case. 
Well, that's for the GNOME stuff. This is a system-wide change proposal, is it 
not? Additionally, you could still be meeting that requirement here, as a new 
install with the same options selected, that is, to have a swap partition, 
would disable the zram device. That'd be a nice middleground for users like 
myself that don't have enough RAM to waste on a zram device. I'm writing this 
email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where giving half of 
my RAM to zram would kill my system's performance, if not quickly cause OOM.

-- 
John M. Harris, Jr.

[John M. Harris Jr]

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(a)splentity.com&gt;
>  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?

-- 
John M. Harris, Jr.

[Chris Murphy]

On Fri, Jun 5, 2020 at 12:09 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:

>  > Most laptops today have UEFI Secure Boot enabled by default and
>  > therefore hibernation isn't possible. And even when the laptop doesn't
>  > have Secure Boot enabled, there's a forest of bugs. It works for some
>  > people and not others. It was working for me on one laptop in
>  > February, consistently doesn't work now and I haven't gotten a reply
>  > yet from upstream about the problem.
>
>  It may be true that most laptops have "Secure Boot" enabled, but not those
>  running Fedora. We don't have numbers to support that claim, and most devices
>  require "Secure Boot" to be disabled,  or to have the mode changed so that it
>  accepts new keys, to install Fedora. 
Most systems that have UEFI Secure Boot enabled include Microsoft's
signing key. Fedora's shim is signed by Microsoft's signing key. And
shim contains Fedora's signing key, so that it can verify GRUB and the
kernel, both of which are signed by Fedora. It's been this way for ~8
years.


-- 
Chris Murphy

[Chris Murphy]

On Fri, Jun 5, 2020 at 1:18 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
>  > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>  > >
>  > >
>  > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
>  > >
>  > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro
> <mcatanzaro(a)gnome.org&gt;
>  > > > wrote:
>  > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
>  > > > > <lists(a)colorremedies.com&gt;
>  > > > > wrote:
>  > > > >
>  > > > >
>  > > > >
>  > > > > > That is the plan, otherwise the swap-on-zram device probably
> never
>  > > > > > gets used. And then its overhead, which is small but not zero,
> is
>  > > > > > just
>  > > > > > a waste.
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > I thought the plan was to get rid of the disk-based swap partition,
>  > > > > since it has an unacceptable impact on system responsiveness?
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > Default new installations, yes. No disk-based swap partition.
>  > > >
>  > > >
>  > > >
>  > > > For upgrades, there's no mechanism to remove an existing
>  > > > swap-on-drive. And the installer will still permit swap-on-drive being
>  > > > added in custom partitioning. Both of these paths results in two swap
>  > > > devices.
>  > > >
>  > > >
>  > > >
>  > > > We could ask Anaconda, if a custom installation creates swap-on-disk,
>  > > > to remove /etc/systemd/zram-generator.conf. And in that case, users
>  > > > will not get swap-on-zram. And we could also forgo the change being
>  > > > applied on upgrades.
>  > >
>  > >
>  > >
>  > > It may be best to respect the user's decision, and not add a zram device
>  > > on upgraded systems. This would lead to less unexpected behavior. I'd
>  > > support that, for sure :)
>  >
>  >
>  > Contra argument: It also leads to fragmentation of the user base. Most
>  > users use a distribution because they trust the decisions. And while
>  > it is only a preference, not a policy the Workstation Product
>  > Requirements Document says  "Upgrading the system multiple times
>  > through the upgrade process should give a result that is the same as
>  > an original install of Fedora Workstation."
>  >
>  > There is a balancing act here that should be considered because a
>  > large percent of Fedora users upgrade rather than reprovision. It
>  > might even be the majority case.
>
>  Well, that's for the GNOME stuff. This is a system-wide change proposal, is it
>  not? 
It is intended for all editions and spins.


> Additionally, you could still be meeting that requirement here, as a
> new
>  install with the same options selected, that is, to have a swap partition,
>  would disable the zram device. That'd be a nice middleground for users like
>  myself that don't have enough RAM to waste on a zram device. I'm writing this
>  email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where giving half of
>  my RAM to zram would kill my system's performance, if not quickly cause OOM. 
Ok so you've just decided to ignore that this is used already for
years on ARM and Fedora IoT (including my 512M Raspberry Pi), and
somehow you think your use case wouldn't benefit even though you
haven't tried it? Maybe try it? You do not need to wait for F33. You
can disable disk based swap and install the zram-generator right now
on F31 or F32.

Your use case is *exactly* what this feature has in mind. And it's
even used by default in Chrome OS and Android when they moved to
kernel 4.4, although not all OEM's opted in.

By all means find a problem. Now is the perfect time for that. I am
beginning to think this feature is like magic and I really want to see
an edge case that blows up magnificently. In a year of testing I
haven't found one that's worse than disk based swap.

-- 
Chris Murphy

[Samuel Sieb]

On 6/5/20 12:18 PM, John M. Harris Jr wrote:
>  Well, that's for the GNOME stuff. This is a system-wide change
> proposal, is it
>  not? Additionally, you could still be meeting that requirement here, as a new
>  install with the same options selected, that is, to have a swap partition,
>  would disable the zram device. That'd be a nice middleground for users like
>  myself that don't have enough RAM to waste on a zram device. I'm writing this
>  email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where giving half of
>  my RAM to zram would kill my system's performance, if not quickly cause OOM. 
I think you've completely missed the technical description of how this 
works.  It does not take more than a tiny bit of RAM when it's not being 
used.  It definitely does not take half your RAM right away.  It only 
starts using RAM when you would otherwise be going into swap.  Then it 
takes those pages that would be going to disk and compresses them so 
they use less RAM.  So no it will not kill your system's performance and 
will help avoid the OOM condition.

[Igor Raits]

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

On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
>  On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
>  > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <
>  > johnmh(a)splentity.com&gt;
>  > wrote:
>  > > 
>  > > 
>  > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
>  > > 
>  > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro <
>  > > > mcatanzaro(a)gnome.org&gt;
>  > > > wrote:
>  > > > 
>  > > > > 
>  > > > > 
>  > > > > 
>  > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
>  > > > > <lists(a)colorremedies.com&gt;
>  > > > > wrote:
>  > > > > 
>  > > > > 
>  > > > > 
>  > > > > > That is the plan, otherwise the swap-on-zram device
>  > > > > > probably never
>  > > > > > gets used. And then its overhead, which is small but not
>  > > > > > zero, is
>  > > > > > just
>  > > > > > a waste.
>  > > > > 
>  > > > > 
>  > > > > 
>  > > > > 
>  > > > > 
>  > > > > I thought the plan was to get rid of the disk-based swap
>  > > > > partition,
>  > > > > since it has an unacceptable impact on system responsiveness?
>  > > > 
>  > > > 
>  > > > 
>  > > > 
>  > > > Default new installations, yes. No disk-based swap partition.
>  > > > 
>  > > > 
>  > > > 
>  > > > For upgrades, there's no mechanism to remove an existing
>  > > > swap-on-drive. And the installer will still permit swap-on-
>  > > > drive being
>  > > > added in custom partitioning. Both of these paths results in
>  > > > two swap
>  > > > devices.
>  > > > 
>  > > > 
>  > > > 
>  > > > We could ask Anaconda, if a custom installation creates swap-
>  > > > on-disk,
>  > > > to remove /etc/systemd/zram-generator.conf. And in that case,
>  > > > users
>  > > > will not get swap-on-zram. And we could also forgo the change
>  > > > being
>  > > > applied on upgrades.
>  > > 
>  > > 
>  > > 
>  > > It may be best to respect the user's decision, and not add a zram
>  > > device
>  > > on upgraded systems. This would lead to less unexpected behavior.
>  > > I'd
>  > > support that, for sure :)
>  > 
>  > 
>  > Contra argument: It also leads to fragmentation of the user base.
>  > Most
>  > users use a distribution because they trust the decisions. And
>  > while
>  > it is only a preference, not a policy the Workstation Product
>  > Requirements Document says  "Upgrading the system multiple times
>  > through the upgrade process should give a result that is the same
>  > as
>  > an original install of Fedora Workstation."
>  > 
>  > There is a balancing act here that should be considered because a
>  > large percent of Fedora users upgrade rather than reprovision. It
>  > might even be the majority case.
>  
>  Well, that's for the GNOME stuff. This is a system-wide change
>  proposal, is it 
>  not? Additionally, you could still be meeting that requirement here,
>  as a new 
>  install with the same options selected, that is, to have a swap
>  partition, 
>  would disable the zram device. That'd be a nice middleground for
>  users like 
>  myself that don't have enough RAM to waste on a zram device. I'm
>  writing this 
>  email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where
>  giving half of 
>  my RAM to zram would kill my system's performance, if not quickly
>  cause OOM. 
Either you did not read the page or I misunderstand how zram works. It
will take 3G of your memory and call it a SWAP. With a compression. So
essentially, if the starts will be aligned you will end up with 9G of
memory. Of course, if that is not enough, you can add on top of that
swap on the disk.

>  -- 
>  John M. Harris, Jr.
>  
>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7anxkACgkQEV1auJxc
> Hh6kqg//a/iT6Cdeg9ZJrfuj/0xWerydUtwRwveG1GoUp6gHK92rDlADWreOpKtw
> p+aGbG/L01Mp4KrNJdwND4/5iy8F7/kB8DfBoEGVT7BNg2KRh/OQLmA5r0LVn6RE
> lEk+BbwDhHEsZoQQH5bicvMEMwO2J+kUL9edAH2ZW6ZQrsXilXIJxogUUuAoR9fH
> EaqadUaF5eWK3qf1HbMV5ffcraN6de+MYxA1C4peQoq5Dr8FPxjoZTl9ECtRMlpw
> 5utWnwwQZAQ9SDXyiIP1oJ3s+iR34eDwXr2V8Aq1940hoGbPsAOH1n6DNWkKULPq
> 6cnZE6tcCIu0bP3Gh7pmmtUZprK5yvIqdgGRXP+nImEXT0AevH3R/VTEsVQsL6f1
> Qu4+MbsC5+hfHUj1JX9M2TDYztCtmcDO6q9P15dmG8KmemEeKZ4iAUsh3kZCq8p4
> L9afY1quySpmnhpIFe68TjcIobclEOLSo9gtDbIgSvuPtVaPEXUpNqm/kP944CNv
> NGjLG8LJ+hWETbkji465ny6CSJS+vDj2LXu+Bv7ilhgjoV3PDwU0JGVSfSCEXb04
> H8tl0KwSYH2QrOZZk89l5vlpjx2UEJwEQhXM/tHJAWDPRvyJSZdPVrBAlIBGSLpb
> hS4JJ5Em0ovA6jUK4kRHlm5xcuizrCfix/bCkp7MzIB0S4UkRbc=
> =kJR5
> -----END PGP SIGNATURE-----

[Igor Raits]

-----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(a)splentity.com&gt;
>  > 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(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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----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-----

[John M. Harris Jr]

On Friday, June 5, 2020 12:38:01 PM MST Igor Raits wrote:
>  On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
>  
>  > On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
>  > 
>  > > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <
>  > > johnmh(a)splentity.com&gt;
>  > > wrote:
>  > > 
>  > > >
>  > > >
>  > > >
>  > > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
>  > > >
>  > > >
>  > > >
>  > > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro <
>  > > > > mcatanzaro(a)gnome.org&gt;
>  > > > > wrote:
>  > > > >
>  > > > >
>  > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
>  > > > > > <lists(a)colorremedies.com&gt;
>  > > > > > wrote:
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > > > That is the plan, otherwise the swap-on-zram device
>  > > > > > > probably never
>  > > > > > > gets used. And then its overhead, which is small but not
>  > > > > > > zero, is
>  > > > > > > just
>  > > > > > > a waste.
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > > I thought the plan was to get rid of the disk-based swap
>  > > > > > partition,
>  > > > > > since it has an unacceptable impact on system responsiveness?
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > Default new installations, yes. No disk-based swap partition.
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > For upgrades, there's no mechanism to remove an existing
>  > > > > swap-on-drive. And the installer will still permit swap-on-
>  > > > > drive being
>  > > > > added in custom partitioning. Both of these paths results in
>  > > > > two swap
>  > > > > devices.
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > We could ask Anaconda, if a custom installation creates swap-
>  > > > > on-disk,
>  > > > > to remove /etc/systemd/zram-generator.conf. And in that case,
>  > > > > users
>  > > > > will not get swap-on-zram. And we could also forgo the change
>  > > > > being
>  > > > > applied on upgrades.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > It may be best to respect the user's decision, and not add a zram
>  > > > device
>  > > > on upgraded systems. This would lead to less unexpected behavior.
>  > > > I'd
>  > > > support that, for sure :)
>  > >
>  > >
>  > >
>  > >
>  > > Contra argument: It also leads to fragmentation of the user base.
>  > > Most
>  > > users use a distribution because they trust the decisions. And
>  > > while
>  > > it is only a preference, not a policy the Workstation Product
>  > > Requirements Document says  "Upgrading the system multiple times
>  > > through the upgrade process should give a result that is the same
>  > > as
>  > > an original install of Fedora Workstation."
>  > >
>  > >
>  > >
>  > > There is a balancing act here that should be considered because a
>  > > large percent of Fedora users upgrade rather than reprovision. It
>  > > might even be the majority case.
>  >
>  >
>  >
>  > Well, that's for the GNOME stuff. This is a system-wide change
>  > proposal, is it
>  > not? Additionally, you could still be meeting that requirement here,
>  > as a new
>  > install with the same options selected, that is, to have a swap
>  > partition,
>  > would disable the zram device. That'd be a nice middleground for
>  > users like
>  > myself that don't have enough RAM to waste on a zram device. I'm
>  > writing this
>  > email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where
>  > giving half of
>  > my RAM to zram would kill my system's performance, if not quickly
>  > cause OOM.
>  
>  
>  Either you did not read the page or I misunderstand how zram works. It
>  will take 3G of your memory and call it a SWAP. With a compression. So
>  essentially, if the starts will be aligned you will end up with 9G of
>  memory. Of course, if that is not enough, you can add on top of that
>  swap on the disk. 
How in the world would I end up with 9G of memory? That's not how this tech 
works, at all. Compression doesn't magically mean you get 2x the amount of 
memory as you reserve for it. Compression rates even for plaintext aren't 
normally that high.

-- 
John M. Harris, Jr.

[Dominique Martinet]

Igor Raits wrote on Fri, Jun 05, 2020:
>  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. 
There is zstd support in our kernels now so that would be good to
compare, I'm seeing impressive results but as this is workload-dependent
it is hard to test from an objective point of view, but this is rather
impressive:

# zramctl 
NAME       ALGORITHM DISKSIZE   DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd            1G 753.4M 150.6M 158.8M       8 [SWAP]

(enabled 15 or so days ago manually; according to smem I have bits of
qemu, firefox, libreoffice, xorg, urxvt and most of lightdm,
sd-pam, rpc.mountd.. in swap so it is quite varied)



Either way +1 from me, I've just installed the generator and manually
set the limit to 4G/0.5 as suggested in the change; I think such a
config file should be added to the f32 rpm so people can try more
easily to convince themselves with the actual config that would be
installed.


Cheers,
-- 
Dominique

[John M. Harris Jr]

On Friday, June 5, 2020 12:39:05 PM MST Igor Raits wrote:
>  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(a)splentity.com&gt;
>  > > 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. 
What makes sense for desktops doesn't necessarily make sense for servers, or 
other environments. Fedora isn't just a desktop distro. Additionally, what 
GNOME folks believe to be best is normally not the best for other desktop 
environments.

-- 
John M. Harris, Jr.

[Hans de Goede]

Hi,

On 6/5/20 9:43 PM, John M. Harris Jr wrote:
>  On Friday, June 5, 2020 12:38:01 PM MST Igor Raits wrote:
> > On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
> >
> >> On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote:
> >>
> >>> On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <
> >>> johnmh(a)splentity.com&gt;
> >>> wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro <
> >>>>> mcatanzaro(a)gnome.org&gt;
> >>>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy
> >>>>>> <lists(a)colorremedies.com&gt;
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> That is the plan, otherwise the swap-on-zram device
> >>>>>>> probably never
> >>>>>>> gets used. And then its overhead, which is small but not
> >>>>>>> zero, is
> >>>>>>> just
> >>>>>>> a waste.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I thought the plan was to get rid of the disk-based swap
> >>>>>> partition,
> >>>>>> since it has an unacceptable impact on system responsiveness?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Default new installations, yes. No disk-based swap partition.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> For upgrades, there's no mechanism to remove an existing
> >>>>> swap-on-drive. And the installer will still permit swap-on-
> >>>>> drive being
> >>>>> added in custom partitioning. Both of these paths results in
> >>>>> two swap
> >>>>> devices.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> We could ask Anaconda, if a custom installation creates swap-
> >>>>> on-disk,
> >>>>> to remove /etc/systemd/zram-generator.conf. And in that case,
> >>>>> users
> >>>>> will not get swap-on-zram. And we could also forgo the change
> >>>>> being
> >>>>> applied on upgrades.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> It may be best to respect the user's decision, and not add a zram
> >>>> device
> >>>> on upgraded systems. This would lead to less unexpected behavior.
> >>>> I'd
> >>>> support that, for sure :)
> >>>
> >>>
> >>>
> >>>
> >>> Contra argument: It also leads to fragmentation of the user base.
> >>> Most
> >>> users use a distribution because they trust the decisions. And
> >>> while
> >>> it is only a preference, not a policy the Workstation Product
> >>> Requirements Document says  "Upgrading the system multiple times
> >>> through the upgrade process should give a result that is the same
> >>> as
> >>> an original install of Fedora Workstation."
> >>>
> >>>
> >>>
> >>> There is a balancing act here that should be considered because a
> >>> large percent of Fedora users upgrade rather than reprovision. It
> >>> might even be the majority case.
> >>
> >>
> >>
> >> Well, that's for the GNOME stuff. This is a system-wide change
> >> proposal, is it
> >> not? Additionally, you could still be meeting that requirement here,
> >> as a new
> >> install with the same options selected, that is, to have a swap
> >> partition,
> >> would disable the zram device. That'd be a nice middleground for
> >> users like
> >> myself that don't have enough RAM to waste on a zram device. I'm
> >> writing this
> >> email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where
> >> giving half of
> >> my RAM to zram would kill my system's performance, if not quickly
> >> cause OOM.
> >
> >
> > Either you did not read the page or I misunderstand how zram works. It
> > will take 3G of your memory and call it a SWAP. With a compression. So
> > essentially, if the starts will be aligned you will end up with 9G of
> > memory. Of course, if that is not enough, you can add on top of that
> > swap on the disk.
>  
>  How in the world would I end up with 9G of memory? That's not how this tech
>  works, at all. Compression doesn't magically mean you get 2x the amount of
>  memory as you reserve for it. Compression rates even for plaintext aren't
>  normally that high. 
Erm, just plain zip reaches 1:3 compression for standard English plain
text.

And in my tests of zram running a full gnome desktop + firefox it reaches
about 1:3 too. I actually started looking into zram after talks with
some Endless engineers, which are using zram on all the devices they
ship and they too were seeing 1:3 compression ratios a lot of apps do
not make very efficient use of RAM, so usually it is quite compressible.
I have been enabling ZRAM by default on all my devices for a while now.

Also I must say that you being so stubborn on this, either not reading
up on it, or refusing to understand how it works is getting really
tiresome.

You seem to insist on having an opinion on this, even though you have
never tried it!

You should really actually give zram a serious try and refrain from
commenting on this thread until you have actually tried zram and given
it a fair chance. As Chris has already said something like your
ThinkPad X200 Tablet with 6 GiB of RAM is more or less exactly what
this is for. Well mostly it is for machines with even less RAM,
but it can help your case too.

Regards,

Hans

[Chris Murphy]

On Fri, Jun 5, 2020 at 1:38 PM Igor Raits
<ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
> I'm
>  > writing this
>  > email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where
>  > giving half of
>  > my RAM to zram would kill my system's performance, if not quickly
>  > cause OOM.
>
>  Either you did not read the page or I misunderstand how zram works. It
>  will take 3G of your memory and call it a SWAP. With a compression. So
>  essentially, if the starts will be aligned you will end up with 9G of
>  memory. Of course, if that is not enough, you can add on top of that
>  swap on the disk. 
That's basically correct. But that 3G swap when full is not free, it
costs 1.5G RAM. It is true that the efficacy of swap-on-zram is not
100% eviction. It's contingent on the compression ratio. If it's 2:1,
the swap-on-zram eviction efficacy is 50%. The memory cost is 1/2 of
the savings. So you save 1/2. If the compression is 3:1 (which I often
see but safer to promote 2:1), 3G /dev/zram0 with full swap costs 1G
RAM, saving 2G. Efficacy is ~67%.

It is super easy to get confused about this, part of which is it seems
like magicsauce, and thus impossible witchcraft. I spent quite a lot
of time wrapping my head around this. And it wasn't hours. It was
days. I won't admit how many days.

Could there be workloads that get close to 1:1 compression? I don't
know. I haven't seen it. A synthetic test filling up anonymous pages
from /dev/urandom should do this. As a workload gets closer to zero
compression, the setup behaves more like noswap. It's not worse than
noswap, but it would be worse than disk based swap. Still, it's way
faster, so you don't see the swap thrashing. I think such a contrived
test could be worth doing just to understand what happens in practice,
not just in theory.

And also? In a year? No kernel panics. So this code is rather robust.
The manifestations will be in user space.

And I've also tested this with and without earlyoom, for many months
each. And have run webkitgtk compile while giving Firefox 80 tabs. And
it is possible with a zram device set to 100% RAM to get into a kind
of nutty CPU/memory based thrashing that doesn't end for a long time -
which is no different than the same set up with disk based swap,
except it lasts even longer to oom and is IO bound.

So far, the worst case is that it doesn't make things better. I
haven't yet seen it make things worse. But they probably exist,
they're just edge cases. And for those workloads, zswap is likely a
better way to spill over onto a disk based swap partition, while still
getting the benefits of a memory cache.

Another likely bad case, is simply overcommitting the system, by
making it do something it flat out has insufficient resources for. We
know the kernel lacks use space interactivity guarantees. This problem
is part of on-going cgroupsv2 resource control to isolate processes
that are essentially runaway, and we'll see more of that work in the
near future too, both GNOME and KDE.

-- 
Chris Murphy

[Igor Raits]

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

On Fri, 2020-06-05 at 12:58 -0700, John M. Harris Jr wrote:
>  On Friday, June 5, 2020 12:39:05 PM MST Igor Raits wrote:
>  > 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(a)splentity.com&gt;
>  > > > 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.
>  
>  What makes sense for desktops doesn't necessarily make sense for
>  servers, or 
>  other environments. Fedora isn't just a desktop distro. Additionally,
>  what 
>  GNOME folks believe to be best is normally not the best for other
>  desktop 
>  environments. 
Can you be more specific about potential problems you see in other use-
cases like server?

>  -- 
>  John M. Harris, Jr.
>  
>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7appIACgkQEV1auJxc
> Hh5Dqw/+MbNqLrRDJb+cYb61f9+M/lvvDIV2OOoYDggchn+gQfUZbW5oEuMUzJY1
> zBCqGUzm0nQovKXZtVigBTcLIW2rl7x9PNrDkF1yI6YpeZ52lQFeC+WlETaOs7f9
> KaF6MRfjKY+w1qEX8zDnvA0lCjZJUkreoPI6YanQ6/GvX6bCABF3QjEEGjQNNcKL
> R6BKFdBKTvI1YHb2lPwNNlK8bDi+IBuEZ466WhaT/tDfGtnvHU6XVYzSwle8W5br
> W0W13xwH/K/40rgff32TFUoczDgB0XzwtEJ6UkJBUjQJV/mSHRuIa7Bwev8BbuNX
> Lik1lEQHAWvAyxCAuVrq45d0dzxHpYHwSp1tKaDZgbn8T0NDIZOJNn1q8T9OFhnM
> ZnnX3TOX2Ey9CaDFCnI6aca4LrRrkdSbcuwwtfefl+zlFqdfMHaBFS+6afMvYLDk
> JfYGVVwg2wKxX9a8YYFAMFshFjbDRT0lKDg+yhvxCdKjzvAxi0bR+7cEbw/NamR6
> NTxsDwG8HNNYMHD8JOM3230uSK22bX1x9c4xzaAgOTtmG6StnekS8nLXs/kZBr1I
> hXyJ58+dCsh0podC7Sanz+XeFdMtxqQN+8Y0KDDY18sA+wYQwt/5GpkWEk4JPrF4
> H2mT7hqm7gNAscXdxAl4b6/yjHR57B5sV2/AU+/XBLIH5JTDuMc=
> =bmkv
> -----END PGP SIGNATURE-----

[Chris Murphy]

On Fri, Jun 5, 2020 at 1:44 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  How in the world would I end up with 9G of memory? That's not how this tech
>  works, at all. Compression doesn't magically mean you get 2x the amount of
>  memory as you reserve for it. Compression rates even for plaintext aren't
>  normally that high. 
If it weighs as much as a duck, it's a witch and we should burn it!

In all the emails you've written, John, you could have this installed
and working by now, and you'd have a much better idea of how this
magic isn't really magic.


-- 
Chris Murphy

[Chris Murphy]

This laptop with 8GiB RAM is running two VMs at the same time: Windows
10 and Fedora Workstation 32. The host is Fedora Workstation 32. And
there is only swap-on-zram sized to 50% RAM. At this compression
ratio, it wouldn't ever end up using more than 25% RAM. I don't expect
to hold a compression ratio of nearly 3:1 over time, the initial
evictions seem to be pretty highly compressible. Not sure why that is.
Anyway 2:1 is a fairly safe bet for the general case.

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7863        7038         131          30         693         529
Swap:          3930         778        3152
$ swapon
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition 3.9G 778M   -2
$ zramctl
NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.9G  777M 240.4M 249.6M       8 [SWAP]
$

In this example, the system evicts 777M, at a cost of 250M, for a
total gain of ~527M.

Quit all VM's...

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7863         678        6283          30         901        6892
Swap:          3930         229        3701
$ swapon
NAME       TYPE      SIZE   USED PRIO
/dev/zram0 partition 3.9G 229.5M   -2
$ zramctl
NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.9G 228.6M   74M 105.1M       8 [SWAP]
$

We see here that it has free'd up swap and memory, having dropped
pages in swap. But there is some zram metadata overhead that is not
dropped for whatever reason. But the net gain is still better than
50%.

--
Chris Murphy

[Kevin Kofler]

Igor Raits wrote:
>  The change says it will use 50% of user’s RAM size, but not more
> than
>  4G. 
But if the machine has only, say, 4 GiB of RAM, then the amount of extra RAM 
you get that way might not be sufficient to avoid OOM.

>  On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote: 
> > Also -1 to adding something to the core system that is written in a
> > language
> > for which we do not even have dynamic linking support. Or even real
> > static
> > linking support, as opposed to packaging libraries as source code.
>  
>  This is not fair. It is a programming language that is safer than C and
>  is already used by some projects that we ship. rpm-ostree, firefox,
>  librsvg2 and others. 
1. librsvg2 and firefox are not really core system components. They are
   UI-related packages (an image processing library and a web browser),
   which is at least one layer higher.
2. rpm-ostree is only a core system component if you use an ostree-based
   installation. In the default Fedora system, it is not.
3. I think that it is a bad enough precedent that even these packages are
   using Rust. We do not have a reasonable way to package software written
   in Rust. Packaging libraries as source code is not reasonable in a binary
   distribution. (And yes, I was opposed to the Go packaging guidelines from
   day 1, and the Rust packaging guidelines copy the same broken concepts,
   so I am opposed to those as well.) As a result, shipping Rust software in
   Fedora is very painful, because everything is essentially statically
   linked (actually compiled on demand at application compile time and then
   statically linked into the application).
4. The Rust toolchain is also inherently foreign on Fedora because it is not
   based on GCC (but on LLVM).

Core system components should be written in C. The higher layers (UI, extra 
CLI tools, etc.) can use C++ as well. IMHO, any other programming language 
is just a pain.

        Kevin Kofler

[Kevin Kofler]

Chris Murphy wrote:
>  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. 
Also, why does this have to be a systemd generator? As a user administrating 
his own systems, I find those to be extremely annoying, because they do 
stuff behind my back that I never asked to happen and I have to mask them 
(and/or uninstall them completely) to get rid of the unwanted behavior.

E.g., the systemd generator that tries to automount partitions not listed in 
fstab based on their GPT UUIDs is just broken. If I do not have the 
partition in the fstab, I left it out for a reason (e.g., the swap partition 
I have on my SSD in case I ever need it, which is normally NOT mounted to 
avoid wearing out the SSD). So why does systemd want to second-guess me and 
mount that partition behind my back unless I go out of my way to mask the 
magic generator?

So why can this zram feature not be a line in fstab, a parameter passed 
through the kernel CLI, or some other solution that is easily tweakable and 
that will definitely not affect upgrades of existing installations (unlike 
yet another systemd generator, if it happens to get installed for whatever 
reason)?

IMHO, the only systemd generator that should ever mount partitions of any 
kind (including virtual ones such as zram) is the systemd-fstab-generator. 
If you want more stuff mounted, it should be added to /etc/fstab, that's 
what that file is for!

        Kevin Kofler

[Samuel Sieb]

I installed the zram package and noticed the systemd-swap package, so 
installed that also.  I adjusted the zram setting to 4G and reduced 
zswap a bit.  I have no idea what that is doing, it doesn't seem to 
affect anything I can measure.  The overall improvement in 
responsiveness is very nice.

On 6/5/20 3:07 PM, Chris Murphy wrote:
>  $ swapon
>  NAME       TYPE      SIZE USED PRIO
>  /dev/zram0 partition 3.9G 778M   -2
>  $ zramctl
>  NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
>  /dev/zram0 lzo-rle       3.9G  777M 240.4M 249.6M       8 [SWAP]
>  $
>  
>  In this example, the system evicts 777M, at a cost of 250M, for a
>  total gain of ~527M. 
I don't understand the numbers I'm getting for these.  I disabled my 
swap partition to force as much to go to zram as possible and then 
turned it back on.

# swapon
NAME      TYPE      SIZE USED  PRIO
/dev/sda3 partition  16G 1.9G    -2
/zram0    partition   4G   4G 32767

This looks like I'm using all 4G of allocated space in the zram swap, but:

# zramctl
NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4             4G  1.8G 658.5M 679.6M       4

This suggests that it's only using 1.8G.  Can you explain what this means?

[Chris Murphy]

On Fri, Jun 5, 2020 at 6:47 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote:
>  I installed the zram package and noticed the systemd-swap package, so
>  installed that also. 
There are conflicting implementations:

anaconda package provides zram.service
zram package provides zram-swap.service
systemd-swap package provides

I've only casually tested systemd-swap package. Note this isn't an
upstream systemd project. Where as the proposed rust zram-generator is
"upstream" in that it's maintained by the same folks, but is not
provided by systemd package I think because it's in rust.

The first two packages I've used a lot and they work, there's nothing
wrong with them. And yes the idea of this proposal is to say bon
voyage, thank you for your service, and then converge on the rust
zram-generator.

There shouldn't be any weird/bad interactions between them, but it is
possible for the user to become very confused which one is working. It
*should* be zram-generator because it runs much earlier during boot
than the others. But I have not thoroughly tested for conflicting
interactions, mainly just sanity testing to make sure things don't
blow up.


> I adjusted the zram setting to 4G and reduced
>  zswap a bit.  I have no idea what that is doing, it doesn't seem to
>  affect anything I can measure.  The overall improvement in
>  responsiveness is very nice. 
It might be you're modifying the configuration of a different
implementation from the one that's actually setting up swaponzram.

>  I don't understand the numbers I'm getting for these.  I
> disabled my
>  swap partition to force as much to go to zram as possible and then
>  turned it back on.
>
>  # swapon
>  NAME      TYPE      SIZE USED  PRIO
>  /dev/sda3 partition  16G 1.9G    -2
>  /zram0    partition   4G   4G 32767
>
>  This looks like I'm using all 4G of allocated space in the zram swap, but:
>
>  # zramctl
>  NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
>  /dev/zram0 lz4             4G  1.8G 658.5M 679.6M       4
>
>  This suggests that it's only using 1.8G.  Can you explain what this means? 
Yeah that's confusing. zramctl just gets info from sysfs, but you
could double check it by

cat /sys/block/zram0/mm_stat

The first value should match "DATA" column in zramctl (which reports in MiB).

While the kernel has long had support for using up to 32 swap devices
at the same time, this is seldom used in practice so it could be an
artifact of this? Indicating that all of this swap is "in use" from
the swap perspective, where zramctl is telling you the truth about
what the zram kernel module is actually using. Is it a cosmetic
reporting bug or intentional? Good question. I'll try to reproduce and
report it upstream and see what they say. But if you beat me to it
that would be great, and then I can just write the email for linux-mm
and cite your bug report. :D


-- 
Chris Murphy

[Samuel Sieb]

On 6/5/20 6:59 PM, Chris Murphy wrote:
>  On Fri, Jun 5, 2020 at 6:47 PM Samuel Sieb <samuel(a)sieb.net&gt;
> wrote:
> >
> > I installed the zram package and noticed the systemd-swap package, so
> > installed that also.
>  
>  There are conflicting implementations:
>  
>  anaconda package provides zram.service
>  zram package provides zram-swap.service
>  systemd-swap package provides 
Did you leave something out?
Are you saying that zram and systemd-swap both provide configuration for 
zram?

>  I've only casually tested systemd-swap package. Note this
> isn't an
>  upstream systemd project. Where as the proposed rust zram-generator is
>  "upstream" in that it's maintained by the same folks, but is not
>  provided by systemd package I think because it's in rust. 
Ok, I was thinking the generator might require rebooting to get it to 
work.  And I saw the systemd-swap package and thought that sounded 
useful to try.

>  There shouldn't be any weird/bad interactions between them, but
> it is
>  possible for the user to become very confused which one is working. It
>  *should* be zram-generator because it runs much earlier during boot
>  than the others. But I have not thoroughly tested for conflicting
>  interactions, mainly just sanity testing to make sure things don't
>  blow up. 
I only started the one service, so I don't think there are any conflicts.

> > I adjusted the zram setting to 4G and reduced
> > zswap a bit.  I have no idea what that is doing, it doesn't seem to
> > affect anything I can measure.  The overall improvement in
> > responsiveness is very nice.
>  
>  It might be you're modifying the configuration of a different
>  implementation from the one that's actually setting up swaponzram. 
No, it was quite clear that I was modifying the right config.  It's the 
/etc/systemd/swap.conf as described in the man page and it was affecting 
the result.

> > I don't understand the numbers I'm getting for these.  I
> disabled my
> > swap partition to force as much to go to zram as possible and then
> > turned it back on.
> >
> > # swapon
> > NAME      TYPE      SIZE USED  PRIO
> > /dev/sda3 partition  16G 1.9G    -2
> > /zram0    partition   4G   4G 32767
> >
> > This looks like I'm using all 4G of allocated space in the zram swap, but:
> >
> > # zramctl
> > NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
> > /dev/zram0 lz4             4G  1.8G 658.5M 679.6M       4
> >
> > This suggests that it's only using 1.8G.  Can you explain what this means?
>  
>  Yeah that's confusing. zramctl just gets info from sysfs, but you
>  could double check it by
>  
>  cat /sys/block/zram0/mm_stat
>  
>  The first value should match "DATA" column in zramctl (which reports in MiB).
>  
>  While the kernel has long had support for using up to 32 swap devices
>  at the same time, this is seldom used in practice so it could be an
>  artifact of this? Indicating that all of this swap is "in use" from
>  the swap perspective, where zramctl is telling you the truth about
>  what the zram kernel module is actually using. Is it a cosmetic
>  reporting bug or intentional? Good question. I'll try to reproduce and
>  report it upstream and see what they say. But if you beat me to it
>  that would be great, and then I can just write the email for linux-mm
>  and cite your bug report. :D 
Part of my concern is that if it's not actually full, then why is it 
using so much of the disk swap?
For upstream, do you mean the kernel?

[Chris Murphy]

On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote:
>  On 6/5/20 6:59 PM, Chris Murphy wrote:
>  > On Fri, Jun 5, 2020 at 6:47 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote:
>  >>
>  >> I installed the zram package and noticed the systemd-swap package, so
>  >> installed that also.
>  >
>  > There are conflicting implementations:
>  >
>  > anaconda package provides zram.service
>  > zram package provides zram-swap.service
>  > systemd-swap package provides
>
>  Did you leave something out? 
systemd-swap package provides systemd-swap.service

>  Are you saying that zram and systemd-swap both provide configuration
> for
>  zram? 
All three of those listed provide competing configurations for swap on
zram. Just to make a fine point, zram is generic, it is not swap
specific. It's just a compressed ram disk. Zswap is a different thing,
it is swap specific, providing a memory based writeback cache to a
disk based swap.




>  > I've only casually tested systemd-swap package. Note this isn't an
>  > upstream systemd project. Where as the proposed rust zram-generator is
>  > "upstream" in that it's maintained by the same folks, but is not
>  > provided by systemd package I think because it's in rust.
>
>  Ok, I was thinking the generator might require rebooting to get it to
>  work.  And I saw the systemd-swap package and thought that sounded
>  useful to try. 
The generator does require a reboot to change configurations. You
could absolutely say, but Chris, the other ones you can just systemctl
restart! That is true, but except for testing, I don't see that as an
advantage compared to the overall simplisticity of zram-generator and
reusing the existing infrastructure in systemd that's already well
tested and maintained.


>  > There shouldn't be any weird/bad interactions between them, but it is
>  > possible for the user to become very confused which one is working. It
>  > *should* be zram-generator because it runs much earlier during boot
>  > than the others. But I have not thoroughly tested for conflicting
>  > interactions, mainly just sanity testing to make sure things don't
>  > blow up.
>
>  I only started the one service, so I don't think there are any conflicts. 
So what you can do is disable all the above listed service units. And
you'll be testing the zram-generator alone. The config file for that
is /etc/systemd/zram-generator.conf

Since there isn't yet an option to set swap priority, chances are it
gets auto-assigned during boot by the kernel. Usually /dev/zram0 comes
first and should get -2 priority and /dev/swapondisk will get a -3. In
that case, zram is higher priority already. But if flipped, you can
just:

swapoff /dev/zram0
swapon -p 3000 /dev/zram0

Although really any value higher than the disk based swap is sufficient.



>  >> I adjusted the zram setting to 4G and reduced
>  >> zswap a bit.  I have no idea what that is doing, it doesn't seem to
>  >> affect anything I can measure.  The overall improvement in
>  >> responsiveness is very nice.
>  >
>  > It might be you're modifying the configuration of a different
>  > implementation from the one that's actually setting up swaponzram.
>
>  No, it was quite clear that I was modifying the right config.  It's the
>  /etc/systemd/swap.conf as described in the man page and it was affecting
>  the result. 
OK that is not for zram-generator. That's for one of the others. Off
hand I don't know which one it's for, this is way too confusing
because of all the competing implementations, which is part of the
motivation of the feature -> buh bye, thank you for your service!


>  >> I don't understand the numbers I'm getting for these.  I disabled my
>  >> swap partition to force as much to go to zram as possible and then
>  >> turned it back on.
>  >>
>  >> # swapon
>  >> NAME      TYPE      SIZE USED  PRIO
>  >> /dev/sda3 partition  16G 1.9G    -2
>  >> /zram0    partition   4G   4G 32767
>  >>
>  >> This looks like I'm using all 4G of allocated space in the zram swap, but:
>  >>
>  >> # zramctl
>  >> NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
>  >> /dev/zram0 lz4             4G  1.8G 658.5M 679.6M       4
>  >>
>  >> This suggests that it's only using 1.8G.  Can you explain what this means?
>  >
>  > Yeah that's confusing. zramctl just gets info from sysfs, but you
>  > could double check it by
>  >
>  > cat /sys/block/zram0/mm_stat
>  >
>  > The first value should match "DATA" column in zramctl (which reports in
> MiB).
>  >
>  > While the kernel has long had support for using up to 32 swap devices
>  > at the same time, this is seldom used in practice so it could be an
>  > artifact of this? Indicating that all of this swap is "in use" from
>  > the swap perspective, where zramctl is telling you the truth about
>  > what the zram kernel module is actually using. Is it a cosmetic
>  > reporting bug or intentional? Good question. I'll try to reproduce and
>  > report it upstream and see what they say. But if you beat me to it
>  > that would be great, and then I can just write the email for linux-mm
>  > and cite your bug report. :D
>
>  Part of my concern is that if it's not actually full, then why is it
>  using so much of the disk swap? 
Not sure. What should be true is if you swapoff on /dev/sda3 it'll
move any referenced anon pages to /dev/zram0. And then if you swapon
/dev/sda3 it will use 0 bytes until /dev/zram0 is full. What kernel
version are you using?

>  For upstream, do you mean the kernel? 
Yes. bugzilla.kernel.org - this goes to the linux-mm folks (memory
management) but you can search for a zram bug and just see what
component they use and post the bug here and I'll pick it up.



-- 
Chris Murphy

[Samuel Sieb]

On 6/5/20 7:33 PM, Chris Murphy wrote:
>  On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb <samuel(a)sieb.net&gt;
> wrote:
>  All three of those listed provide competing configurations for swap on
>  zram. Just to make a fine point, zram is generic, it is not swap
>  specific. It's just a compressed ram disk. Zswap is a different thing,
>  it is swap specific, providing a memory based writeback cache to a
>  disk based swap. 
Ok, that makes sense about zram.  It's a lot simpler than I was thinking 
it was.

>  The generator does require a reboot to change configurations. You
>  could absolutely say, but Chris, the other ones you can just systemctl
>  restart! That is true, but except for testing, I don't see that as an
>  advantage compared to the overall simplisticity of zram-generator and
>  reusing the existing infrastructure in systemd that's already well
>  tested and maintained. 
Sure, I'll set that up for the next time I reboot.  But that is likely 
to still be a long time from now.

>  Although really any value higher than the disk based swap is
> sufficient. 
The systemd-swap service appears to set the priority of zram to the 
maximum possible.

> > No, it was quite clear that I was modifying the right config. 
> It's the
> > /etc/systemd/swap.conf as described in the man page and it was affecting
> > the result.
>  
>  OK that is not for zram-generator. That's for one of the others. Off
>  hand I don't know which one it's for, this is way too confusing
>  because of all the competing implementations, which is part of the
>  motivation of the feature -> buh bye, thank you for your service! 
Sorry, I guess that wasn't clear.  That's the config file for 
systemd-swap which is what I was testing.

> > Part of my concern is that if it's not actually full, then
> why is it
> > using so much of the disk swap?
>  
>  Not sure. What should be true is if you swapoff on /dev/sda3 it'll
>  move any referenced anon pages to /dev/zram0. And then if you swapon
>  /dev/sda3 it will use 0 bytes until /dev/zram0 is full. What kernel
>  version are you using? 
That is what I did do.
kernel 5.5.17-200.fc31.x86_64

> > For upstream, do you mean the kernel?
>  
>  Yes. bugzilla.kernel.org - this goes to the linux-mm folks (memory
>  management) but you can search for a zram bug and just see what
>  component they use and post the bug here and I'll pick it up. 
I reset everything and now I can't reproduce it.  I wonder if it was 
because I had zswap enabled as well.  When I was going to file the bug 
report, I came across a comment that it's not beneficial to use them 
both at the same time.

# swapon
NAME      TYPE      SIZE USED  PRIO
/dev/sda3 partition  16G   0B    -2
/zram0    partition   5G 4.6G 32767

# zramctl
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4             5G  4.6G  1.5G  1.5G       4

It looks like it's working properly now.  So it seems likely that it was 
user error.  And for the little it matters, I approve of the change 
proposal.  I will have to test it out on my other systems as well now.

[Chris Murphy]

On Fri, Jun 5, 2020 at 8:33 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote:
>  >
>  > >> # swapon
>  > >> NAME      TYPE      SIZE USED  PRIO
>  > >> /dev/sda3 partition  16G 1.9G    -2
>  > >> /zram0    partition   4G   4G 32767
>  > >>
>  > >> This looks like I'm using all 4G of allocated space in the zram swap,
> but:
>  > >>
>  > >> # zramctl
>  > >> NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
>  > >> /dev/zram0 lz4             4G  1.8G 658.5M 679.6M       4
>  > >>
>  > >> This suggests that it's only using 1.8G.  Can you explain what this
> means?
>  > >
>  > > Yeah that's confusing. zramctl just gets info from sysfs, but you
>  > > could double check it by
>  > >
>  > > cat /sys/block/zram0/mm_stat
>  > >
>  > > The first value should match "DATA" column in zramctl (which reports
> in MiB).
>  > >
>  > > While the kernel has long had support for using up to 32 swap devices
>  > > at the same time, this is seldom used in practice so it could be an
>  > > artifact of this? Indicating that all of this swap is "in use" from
>  > > the swap perspective, where zramctl is telling you the truth about
>  > > what the zram kernel module is actually using. Is it a cosmetic
>  > > reporting bug or intentional? Good question. I'll try to reproduce and
>  > > report it upstream and see what they say. But if you beat me to it
>  > > that would be great, and then I can just write the email for linux-mm
>  > > and cite your bug report. :D
>  >
>  > Part of my concern is that if it's not actually full, then why is it
>  > using so much of the disk swap? 
OK I can't explain what you're seeing because I'm not certain of the
workload. Here's what I've got going on.

F32, 5.7.0-fc33 kernel, 8G RAM, 4G swaponzram, 10G swapondrive. With
swaponzram higher priority before doing any swapping.

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7864        1395        4251          60        2216        6122
Swap:         14559           0       14559
$ swapon
NAME       TYPE       SIZE USED PRIO
/dev/sda5  partition 10.4G   0B   -2
/dev/zram0 partition  3.9G   0B    3
$ zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.9G   4K   74B   12K       8 [SWAP]

 Then build webkitgtk using 'ninja -j10'

What happens? Only the swaponzram0 is used for a while. It fills up
and then swaponsda5 starts being used. But also, the used on swapzram0
goes down and up and down and up. During this time, swaponsda5 mostly
doesn't change. Sometimes it goes down. But it only goes back up again
if swaponzram0 is already full.

I think this is working as I expect because once anonymous pages are
in either swap, they don't migrate between the swaps. But anonymous
pages can always be deallocated from either swap at any time leading
to the appearance that zram0 isn't being used to the max - well
because it's not.

Here is an example.

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7864        5613        1945          63         305        1929
Swap:         14559        4745        9814
$ swapon
NAME       TYPE       SIZE USED PRIO
/dev/sda5  partition 10.4G 1.9G   -2
/dev/zram0 partition  3.9G 2.6G    3
$ zramctl
NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.9G  2.4G 582.1M 877.6M       8 [SWAP]
$

The gap between COMPR and TOTAL might seem big. And in fact it might
be fragmentation not metadata overhead, as was earlier suggested. But
it changes a lot and fast with this workload. Just a couple minutes
later.

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7864        7602         125           1         136          56
Swap:         14559        7342        7216
$ swapon
NAME       TYPE       SIZE USED PRIO
/dev/sda5  partition 10.4G 3.4G   -2
/dev/zram0 partition  3.9G 3.9G    3
$ zramctl
NAME       ALGORITHM DISKSIZE  DATA  COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.9G  3.9G 913.1M  954M       8 [SWAP]
$

I'm getting 4:1 compression ratio with this workload, by the way. It's
so far not using more than 1GiB RAM to save me 4G. Or a net savings of
3G that is regular memory. But more importantly than the compression?
The fact 4GiB did not need to page out and back in from SSD. And in
fact as the workload progresses, it's saving quite a lot more than 4G
of pageouts to disk - I just don't have a cumulative value. Also? The
workload has a high wait state for CPU when it's IO bound, waiting on
the drive, even though it's an SSD. The zram based swap is only as
smart as the workload is at properly deallocating things that it no
longer needs. If it's holding onto anonymous pages and they're in the
swap-on-zram device, then that's it, back to disk swapping only.

I haven't yet seen swapon claim swap was full but then zramctl say it
wasn't. But this changes fast, depending on the workload. And also, it
might be true there's some latency in the reporting between them.



-- 
Chris Murphy

[John M. Harris Jr]

On Friday, June 5, 2020 5:19:55 PM MST Kevin Kofler wrote:
>  Chris Murphy wrote:
>  
>  > 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.
>  
>  
>  Also, why does this have to be a systemd generator? As a user administrating
>   his own systems, I find those to be extremely annoying, because they do
>  stuff behind my back that I never asked to happen and I have to mask them
>  (and/or uninstall them completely) to get rid of the unwanted behavior. 
>  E.g., the systemd generator that tries to automount partitions not listed in
>   fstab based on their GPT UUIDs is just broken. If I do not have the
>  partition in the fstab, I left it out for a reason (e.g., the swap
>  partition I have on my SSD in case I ever need it, which is normally NOT
>  mounted to avoid wearing out the SSD). So why does systemd want to
>  second-guess me and mount that partition behind my back unless I go out of
>  my way to mask the magic generator?
>  
>  So why can this zram feature not be a line in fstab, a parameter passed 
>  through the kernel CLI, or some other solution that is easily tweakable and
>   that will definitely not affect upgrades of existing installations
>  (unlike yet another systemd generator, if it happens to get installed for
>  whatever reason)?
>  
>  IMHO, the only systemd generator that should ever mount partitions of any 
>  kind (including virtual ones such as zram) is the systemd-fstab-generator. 
>  If you want more stuff mounted, it should be added to /etc/fstab, that's
>  what that file is for! 
Completely agreed, going about it this way would also address most of my 
concerns with this change, as it would mean it's easy for people like myself 
to opt out.

-- 
John M. Harris, Jr.

[Samuel Sieb]

On 6/5/20 11:43 PM, John M. Harris Jr wrote:
>  Completely agreed, going about it this way would also address most of
> my
>  concerns with this change, as it would mean it's easy for people like myself
>  to opt out. 
If you don't want it, then disable the generator or uninstall it.  I 
don't understand why you're so against this.  It's not even really new. 
Is it because you don't understand it?  Try it, you'll like it.  It made 
such a big difference on my laptop.  I'm going to be activating it on my 
other computers and servers as I get time.  Most of the servers have 
enough RAM to not need swap, but it makes a nice safety net with 
virtually no overhead.

[John M. Harris Jr]

On Friday, June 5, 2020 11:57:50 PM MST Samuel Sieb wrote:
>  On 6/5/20 11:43 PM, John M. Harris Jr wrote:
>  
>  > Completely agreed, going about it this way would also address most of my
>  > concerns with this change, as it would mean it's easy for people like
>  > myself to opt out.
>  
>  
>  If you don't want it, then disable the generator or uninstall it.  I 
>  don't understand why you're so against this.  It's not even really new. 
>  Is it because you don't understand it?  Try it, you'll like it.  It made 
>  such a big difference on my laptop.  I'm going to be activating it on my 
>  other computers and servers as I get time.  Most of the servers have 
>  enough RAM to not need swap, but it makes a nice safety net with 
>  virtually no overhead. 
On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, enabling 
swap on zram led to increased CPU usage (Always above 13% where normally 
idling at 6%!), and my entire system freezing after about 30 minutes. In all 
fairness, I don't know why my system froze, as I couldn't get anything over 
netconsole and sysrq wasn't working, but I think I'm going to leave it 
disabled. Swap on disk is more than fast enough for buffer/cache and 
hibernation/resume on my system.

I don't know why people seem to be repeating what seems to be the result of a 
placebo, saying that their system "feels more responsive" with swap on zram. 
People seem to be forgetting why swap on zram came up to begin with, it has 
nothing to do with system "responsiveness", which wasn't an issue. It had to

do with dealing with OOM. Swap on zram isn't even a solution to that, it just 
changes how specifically it affects systems.

For servers, swap is useful regardless of the amount of RAM. Swap is very nice 
for use as buffer/cache, and leaves space in RAM for whatever the server is 
running. For example, I always configure a 4 GiB swap partition on servers 
with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 GiB, 16 GiB on 
servers with 128-256 GiB, etc. Beyond that, tuning is a bit different 
depending on the workload, but it sets a very nice starting point.

-- 
John M. Harris, Jr.

[Samuel Sieb]

On 6/6/20 12:42 AM, John M. Harris Jr wrote:
>  On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM,
> enabling
>  swap on zram led to increased CPU usage (Always above 13% where normally
>  idling at 6%!), and my entire system freezing after about 30 minutes. In all
>  fairness, I don't know why my system froze, as I couldn't get anything over
>  netconsole and sysrq wasn't working, but I think I'm going to leave it
>  disabled. Swap on disk is more than fast enough for buffer/cache and
>  hibernation/resume on my system. 
I don't know why you had problems with it, but it's working on fine on 
every system I've tried it on.  It's not increasing my CPU usage.  It's 
probably actually lower due to less swap thrashing.

>  I don't know why people seem to be repeating what seems to be the
> result of a
>  placebo, saying that their system "feels more responsive" with swap on zram.
>  People seem to be forgetting why swap on zram came up to begin with, it has
>  nothing to do with system "responsiveness", which wasn't an issue. It had
> to
>  do with dealing with OOM. Swap on zram isn't even a solution to that, it just
>  changes how specifically it affects systems. 
See, this is a clear indication that you don't understand what it is 
doing and weren't listening to the various people trying to explain it. 
It is definitely not a placebo.  I gave zram 5G out of the 12G I have 
and my laptop is performing way better now.  It's not thrashing the disk 
(SSD) every time I switch desktops or windows.  Due to the number and 
size of applications I'm running, I normally have to close Thunderbird 
when I want to run Chrome.  But now I can start Chrome up with no 
problem.  I converted my running system with no reboots and I didn't 
change anything else about how I'm using the laptop.

# zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4             5G   5G  1.7G  1.8G       4

5GB of swap space that normally would be on disk is now taking less than 
2G of RAM.  Instead of the usual 6G in the disk swap, now I have less 
than 2.

>  For servers, swap is useful regardless of the amount of RAM. Swap is
> very nice
>  for use as buffer/cache, and leaves space in RAM for whatever the server is
>  running. For example, I always configure a 4 GiB swap partition on servers
>  with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 GiB, 16 GiB on
>  servers with 128-256 GiB, etc. Beyond that, tuning is a bit different
>  depending on the workload, but it sets a very nice starting point. 
Swap is never used as buffer or cache, that doesn't even make sense. 
Buffer is storing data before writing it to disk and cache is keeping 
hot data somewhere with fast access.  Why do you use so much swap on 
your servers?  The linear correlation with RAM is an obsolete idea and 
was only somewhat valid when memory sizes were smaller.  If you're using 
any significant fraction of that swap space, your server is in trouble.

[Kevin Kofler]

John M. Harris Jr wrote:
>  On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB
> RAM,
>  enabling swap on zram led to increased CPU usage (Always above 13% where
>  normally idling at 6%!), and my entire system freezing after about 30
>  minutes. In all fairness, I don't know why my system froze, as I couldn't
>  get anything over netconsole and sysrq wasn't working, but I think I'm
>  going to leave it disabled. Swap on disk is more than fast enough for
>  buffer/cache and hibernation/resume on my system. 
You actually made another point there, between the lines: hibernation/resume 
is actually never going to work with zram, by design. You cannot hibernate 
to something that is no more persistent than the RAM (because it is actually 
just a compressed virtual disk within that exact same RAM).

>  For servers, swap is useful regardless of the amount of RAM. Swap is
> very
>  nice for use as buffer/cache, and leaves space in RAM for whatever the
>  server is running. For example, I always configure a 4 GiB swap partition
>  on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128
>  GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a bit
>  different depending on the workload, but it sets a very nice starting
>  point. 
I actually created 32 GiB of swap on my desktop with 16 GiB of RAM. Twice 
the RAM, as used to be the norm. Though admittedly, much of it sits unused 
all the time, and most of the time, the usage is even at 0 altogether. But 
with two 3 GiB HDDs, there is plenty of space for a small swap RAID0 next to 
the data RAID1. (I care about long-term data integrity for the actual data, 
not for swap, which is throwaway content by definition.)

        Kevin Kofler

[Kevin Kofler]

Samuel Sieb wrote:
>  See, this is a clear indication that you don't understand what it
> is
>  doing and weren't listening to the various people trying to explain it.
>  It is definitely not a placebo.  I gave zram 5G out of the 12G I have
>  and my laptop is performing way better now.  It's not thrashing the disk
>  (SSD) every time I switch desktops or windows. 
If you are always running out of RAM with 12 GiB, you need to look into the 
applications you are running. I have a notebook with 4 GiB RAM and 8 GiB 
swap and it is usable with Fedora (KDE Spin), Plasma, and some applications. 
Are you running only standard desktop applications or some memory-intensive 
simulations or something?

>  Due to the number and size of applications I'm running, I
> normally have to
>  close Thunderbird when I want to run Chrome.  But now I can start Chrome
>  up with no problem. 
Wow. I am running Trojitá (IMAP mail) and Falkon (web browser) right now, 
plus Konversation (IRC) and KNode (NNTP, in which I am writing this message 
right now), and KSensors reports 2096 MiB of RAM and 0 MiB of swap used. So 
what is using so much RAM? Are Thunderbird and Chrome so memory-hungry or is 
it the other applications you are running? (Which ones?)

>  Swap is never used as buffer or cache, that doesn't even make
> sense.
>  Buffer is storing data before writing it to disk and cache is keeping
>  hot data somewhere with fast access.  Why do you use so much swap on
>  your servers?  The linear correlation with RAM is an obsolete idea and
>  was only somewhat valid when memory sizes were smaller.  If you're using
>  any significant fraction of that swap space, your server is in trouble. 
He actually has much less swap set up than I do. Not even half his RAM. I 
just stick to twice the RAM, because taking 16 GiB away from a 3 TB RAID1 to 
make room for a 32 GiB RAID0 swap is not going to make any practical 
difference.

        Kevin Kofler

[Kevin Kofler]

Kevin Kofler wrote:
>  with two 3 GiB HDDs 
Correction: two 3 TB HDDs. That was off by a factor 931. :-)

        Kevin Kofler

[David Kaufmann]

Hi!

On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote:
>  5GB of swap space that normally would be on disk is now taking less
> than 2G
>  of RAM.  Instead of the usual 6G in the disk swap, now I have less than 2. 
What's bugging me about this thread is that quite a few people made
comparisions resulting in "compressed zram is smaller than uncompressed
disk swap". For me this seems quite obvious, and looks like flawed
testing.

Wouldn't it be more correct to also compress disk swap to compare size?
This would probably make the size-argument void, as I'd expect them to
be the same size. If it's not, that would be an useful data point.
Also I don't care about 10GB stuff sitting in disk swap, whilst 1GB of
RAM could be quite essential. This leaves overall performance as a
potential benefit of zram swap.

What almost noone wrote about is CPU usage, for which I saw two
anecdotal references: "no change" and "doubled CPU usage".

It would be interesting to see a comparison of swap, compressed swap and
zram swap performance while having processes competing on swap.
E.g. System with 8 GB RAM:
* 2 processes with 3.5 GB memory each
  this would leave about 1GB for the system itself, so with disk swap
  there should be not much swapping and with zram swap I'd expect little
  swapping too.
* 2 processes with 4 GB memory each
  this would force light disk swap usage in the first two cases, I'm not
  really sure what it would do to zram swap.
* 2 processes with 4.5 GB memory each
  this would definitely lead to constant swapping, but it should still
  fit in zram swap, with a ratio of 2:1 it should theoretically fit in a
  2GB zram device, and realistically in a 4GB zram device.

For the programs I'd think of something allocating memory and
writing/reading random parts of it, running for N iterations.
Interesting points would be: average CPU usage and wallclock time for
each of the processes.

I've left out the obvious cases of "not enough memory usage to use any
of those anyway" and "too much memory usage that it results in oom".
oom killer should not invoke in daily usage anyway, I see that as a sign
for "something has gone seriously wrong", comparable with "program
segfaults on start".

All the best,
David

[Igor Raits]

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

On Sat, 2020-06-06 at 02:19 +0200, Kevin Kofler wrote:
>  Chris Murphy wrote:
>  > 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.
>  
>  Also, why does this have to be a systemd generator? As a user
>  administrating 
>  his own systems, I find those to be extremely annoying, because they
>  do 
>  stuff behind my back that I never asked to happen and I have to mask
>  them 
>  (and/or uninstall them completely) to get rid of the unwanted
>  behavior.
>  
>  E.g., the systemd generator that tries to automount partitions not
>  listed in 
>  fstab based on their GPT UUIDs is just broken. If I do not have the 
>  partition in the fstab, I left it out for a reason (e.g., the swap
>  partition 
>  I have on my SSD in case I ever need it, which is normally NOT
>  mounted to 
>  avoid wearing out the SSD). So why does systemd want to second-guess
>  me and 
>  mount that partition behind my back unless I go out of my way to mask
>  the 
>  magic generator?
>  
>  So why can this zram feature not be a line in fstab, a parameter
>  passed 
>  through the kernel CLI, or some other solution that is easily
>  tweakable and 
>  that will definitely not affect upgrades of existing installations
>  (unlike 
>  yet another systemd generator, if it happens to get installed for
>  whatever 
>  reason)?
>  
>  IMHO, the only systemd generator that should ever mount partitions of
>  any 
>  kind (including virtual ones such as zram) is the systemd-fstab-
>  generator. 
>  If you want more stuff mounted, it should be added to /etc/fstab,
>  that's 
>  what that file is for! 
Well, with systemd.mount it is already possible to mount things that
are not in /etc/fstab. That file has same disadvantages as any other
configuration files in «unstructured» format. You can't override some
specific setting of it, disable some mount by simple command (that is
not sed) and so on.

Also if AIUI, it is not trivial to make it work with just fstab because
something has to create a swap during the boot and fstab entry clearly
can't do that.

>          Kevin Kofler
>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bcA8ACgkQEV1auJxc
> Hh5VGA//SNQOQdLoTvqZKdfS9DpPSsvh/Lii/FMe38viOmy6hcAjQJ6Z3PlJX9cb
> e/4i8af/OTzYkoYLQLlRwOfXszcZvKCEtjAJz3yfOTOxwxuItucsC7HeuMXiDlpG
> 3RuV2yLoZFOo+BwlfjFLxvNZRag+w8GLuSLFO0Nes1xjZMNwoI31PVyIykZ60YsH
> LX7vPZ80QOKAQHpPuxChyOIH0uXelGN8Mnl7lVu9jPPaDQaCzbUpcSBTeiNK0MGK
> oUFMXB0zfTZqk0iLI3VVdf3MZl2hro9R4c3AkbDsitcFwlWoMuM07U8jdNvuf0pP
> Zlm5hnZ/Xks3RzC+6wsIqB//ubS5f6WYLt4B/tH4zhAyW2CIxcWx3n9eonLshFX+
> QqS92HuS/KBfcVG5GCpAMVwBdZwikjxbnf0CQ0az34iae2FmKwyVc2jKOwwdwCke
> eGnMeo623p4uuLC+R9LwjQCAK8BHi6dQqRgY+Ybp6ymzPpffqaWzENxRmGeG/0M3
> cNjrsHQlKvxnXhbbungeJIEPVFXn4Y/V1sXOrj5JMW/M9Dk44M3lrATiiiojZDxA
> tRsKgtGKzT4WTp67N4/dnK61ByCDAew39IG8JFUr/2dUDoDkEpXk4mSxcU3K7kln
> +yagnUD6UTTeWWtq76nKer9ydjrN/tdi9yVfHGFXqbKboFKQ/ok=
> =rfaN
> -----END PGP SIGNATURE-----

[Igor Raits]

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

On Sat, 2020-06-06 at 02:09 +0200, Kevin Kofler wrote:
>  Igor Raits wrote:
>  > The change says it will use 50% of user’s RAM size, but not more
>  > than
>  > 4G.
>  
>  But if the machine has only, say, 4 GiB of RAM, then the amount of
>  extra RAM 
>  you get that way might not be sufficient to avoid OOM.
>  
>  > On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote: 
>  > > Also -1 to adding something to the core system that is written in
>  > > a
>  > > language
>  > > for which we do not even have dynamic linking support. Or even
>  > > real
>  > > static
>  > > linking support, as opposed to packaging libraries as source
>  > > code.
>  > 
>  > This is not fair. It is a programming language that is safer than C
>  > and
>  > is already used by some projects that we ship. rpm-ostree, firefox,
>  > librsvg2 and others.
>  
>  1. librsvg2 and firefox are not really core system components. They
>  are
>     UI-related packages (an image processing library and a web
>  browser),
>     which is at least one layer higher.
>  2. rpm-ostree is only a core system component if you use an ostree-
>  based
>     installation. In the default Fedora system, it is not.
>  3. I think that it is a bad enough precedent that even these packages
>  are
>     using Rust. We do not have a reasonable way to package software
>  written
>     in Rust. Packaging libraries as source code is not reasonable in a
>  binary
>     distribution. (And yes, I was opposed to the Go packaging
>  guidelines from
>     day 1, and the Rust packaging guidelines copy the same broken
>  concepts,
>     so I am opposed to those as well.) As a result, shipping Rust
>  software in
>     Fedora is very painful, because everything is essentially
>  statically
>     linked (actually compiled on demand at application compile time
>  and then
>     statically linked into the application). 
Why is it painful? You have all dependencies packaged that follow
semver (not like Go) and it is quite easy to build those packages.

Another example here could be nodejs, even though it does not link
statically it is just PITA to package since ecosystem is just full of
very small libraries that do not really like to cooperate so you need
to have tens of different versions of a lib in a repo. I consider this
much bigger problem than the Rust has in Fedora.

>  4. The Rust toolchain is also inherently foreign on Fedora because
> it
>  is not
>     based on GCC (but on LLVM). 
That way you can say that mesa is foreign because it uses LLVM. If
there is ever alternative compiler to Rust that is based on GCC and has
feature parity, we can definitely consider trying it out. But the
referene compiler works just well.

>  
>  Core system components should be written in C. The higher layers (UI,
>  extra 
>  CLI tools, etc.) can use C++ as well. IMHO, any other programming
>  language 
>  is just a pain. 
We also have Fedora CoreOS that uses
https://github.com/coreos/afterburn and
https://github.com/coreos/zincati that are written in Rust as well and
those are core system utilities.

I don't think saying "Ditch Python, Ruby, Perl, … from the system
components" is useful for anyone since you know that it is not going to
happen.

>          Kevin Kofler
>  _______________________________________________
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bcdkACgkQEV1auJxc
> Hh6Aqg//bbeyDzTLPVhN41P7TU5LeA2d1c/Ya2tjbpvWf3VaWsJ26UDdLUyIXw2c
> r4/C3Kkda7qGHmOSjLRlBvzEMe3e7wO+Xi+16ZyTex6+2M1bxifAXZHTz1wtkhIW
> AmdMvyjJbCrzc3jUG3dj3FfE4PWjS58tZYIvG8XEcRxoyvWOsMRqdaxP0V9Frhr7
> 9hxULUenGpVzvXz+z8/s7rosN4yqTotv1HCFRCworHhXXErVzEy8ha7EjZpGwnyL
> zDssJ0jB+5eMYk94J2NG5ZwBkOSxBfYMEO4dDLQdMPk6jBEfpZg1jS5wIkbUx3UR
> fZpitoOs5snIyh46bjL5ldod9lgJ+j7txSle0tpTbeGsPRqVIq+k7NhRI7s24q+R
> uaJwHDsGRtBaWeTzzykCPlj7kRh/y/fV3TIBzpi5apK1aXxmAZw/RuMXzZK65yFb
> cGQ79jKanOzRMCD97T+ExiBNpk5Oj0dEF3dWlbHAxoHDc5UFRxyizUPPUNGHooTg
> qmnssso/a4MoS0/IdTsHpJP62Xm7tGBm9VfIDkK9GFxBZ+L5nj/43yuBxKUMA2s/
> pWBZ2FiqzLQ0RyD1IqXsUVyoxm3X66FRywkTgUdg56MQAvZQkppdeoBwoP4kBOdS
> Yqnt/GC3iq0bt+7Rt7TQudB5fXOKnFL7oGyrx6zAoct3n+F+HNk=
> =H4dJ
> -----END PGP SIGNATURE-----

[Nicolas Mailhot]

Le samedi 06 juin 2020 à 12:37 +0200, Igor Raits a écrit :
>  
>  Why is it painful? You have all dependencies packaged that follow
>  semver (not like Go) and it is quite easy to build those packages. 
And Go has all build dependencies in the release where they are used
(not like rust, with magic ephemeral rawhide-only packages)

See? Easy to find faults in other people’s work

-- 
Nicolas Mailhot

[Richard W.M. Jones]

On Fri, Jun 05, 2020 at 05:55:26PM +0200, Igor Raits wrote:
>  On Fri, 2020-06-05 at 15:11 +0100, Richard W.M. Jones wrote:
>  > 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. 
Thanks - the fact that the primary swap partition now lives in RAM is
what I was missing.

But let's say we also add a lower priority disk swap, then my next
question ...

>  > 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? 
... means: Does this secondary swap partition (on disk) contain
swapped out zram pages?  Or uncompressed pages?  (Or maybe the
question just makes no sense, I don't really know.)

>  > 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. 
Interesting, thanks.  It looks like zstd is an alternative, although I
don't know which will be better/faster.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Richard W.M. Jones]

On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote:
>  This laptop with 8GiB RAM is running two VMs at the same time:
> Windows
>  10 and Fedora Workstation 32. The host is Fedora Workstation 32. 
So this suggests another interesting question: If I have Fedora
virtual machines running on a Fedora host, and both are using zram,
could there be some negative interaction?  ie. With the pages not
being compressible twice.  I suppose (without looking at the source)
that zram will skip compressing a page if the compressed page is not
any smaller?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Richard W.M. Jones]

On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote:
>  See, this is a clear indication that you don't understand what it
> is
>  doing and weren't listening to the various people trying to explain
>  it. 
Not sure this is needed.  The conversation so far has talked about
many interesting topics which aren't covered in the proposal, and I
value the opinions of people running server / other desktop loads.

(This is without any opinion on whether zram is good or bad - I hadn't
heard about it before, haven't used it, but the technology looks
interesting.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[John M. Harris Jr]

On Saturday, June 6, 2020 3:37:13 AM MST Igor Raits wrote:
>  On Sat, 2020-06-06 at 02:09 +0200, Kevin Kofler wrote:
>  
>  > Igor Raits wrote:
>  > 
>  > > The change says it will use 50% of user’s RAM size, but not more
>  > > than
>  > > 4G.
>  >
>  >
>  >
>  > But if the machine has only, say, 4 GiB of RAM, then the amount of
>  > extra RAM
>  > you get that way might not be sufficient to avoid OOM.
>  >
>  >
>  >
>  > > On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote:
>  > > 
>  > > > Also -1 to adding something to the core system that is written in
>  > > > a
>  > > > language
>  > > > for which we do not even have dynamic linking support. Or even
>  > > > real
>  > > > static
>  > > > linking support, as opposed to packaging libraries as source
>  > > > code.
>  > >
>  > >
>  > >
>  > > This is not fair. It is a programming language that is safer than C
>  > > and
>  > > is already used by some projects that we ship. rpm-ostree, firefox,
>  > > librsvg2 and others.
>  >
>  >
>  >
>  > 1. librsvg2 and firefox are not really core system components. They
>  > are
>  >    UI-related packages (an image processing library and a web
>  > browser),
>  >    which is at least one layer higher.
>  > 2. rpm-ostree is only a core system component if you use an ostree-
>  > based
>  >    installation. In the default Fedora system, it is not.
>  > 3. I think that it is a bad enough precedent that even these packages
>  > are
>  >    using Rust. We do not have a reasonable way to package software
>  > written
>  >    in Rust. Packaging libraries as source code is not reasonable in a
>  > binary
>  >    distribution. (And yes, I was opposed to the Go packaging
>  > guidelines from
>  >    day 1, and the Rust packaging guidelines copy the same broken
>  > concepts,
>  >    so I am opposed to those as well.) As a result, shipping Rust
>  > software in
>  >    Fedora is very painful, because everything is essentially
>  > statically
>  >    linked (actually compiled on demand at application compile time
>  > and then
>  >    statically linked into the application).
>  
>  
>  Why is it painful? You have all dependencies packaged that follow
>  semver (not like Go) and it is quite easy to build those packages.
>  
>  Another example here could be nodejs, even though it does not link
>  statically it is just PITA to package since ecosystem is just full of
>  very small libraries that do not really like to cooperate so you need
>  to have tens of different versions of a lib in a repo. I consider this
>  much bigger problem than the Rust has in Fedora.
>  
>  
>  > 4. The Rust toolchain is also inherently foreign on Fedora because it
>  > is not
>  >    based on GCC (but on LLVM).
>  
>  
>  That way you can say that mesa is foreign because it uses LLVM. If
>  there is ever alternative compiler to Rust that is based on GCC and has
>  feature parity, we can definitely consider trying it out. But the
>  referene compiler works just well.
>  
>  
>  >
>  >
>  > Core system components should be written in C. The higher layers (UI,
>  > extra
>  > CLI tools, etc.) can use C++ as well. IMHO, any other programming
>  > language
>  > is just a pain.
>  
>  
>  We also have Fedora CoreOS that uses
>  https://github.com/coreos/afterburn and
>  https://github.com/coreos/zincati that are written in Rust as well and
>  those are core system utilities. 
Sure, but Fedora CoreOS is not Fedora. Err, not Fedora, the distro. This is 
yet another example of how throwing all of these toys under the Fedora 
umbrella can sound confusing.

-- 
John M. Harris, Jr.

[John M. Harris Jr]

On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote:
>  On 6/6/20 12:42 AM, John M. Harris Jr wrote:
>  
>  > On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM,
>  > enabling swap on zram led to increased CPU usage (Always above 13% where
>  > normally idling at 6%!), and my entire system freezing after about 30
>  > minutes. In all fairness, I don't know why my system froze, as I couldn't
>  > get anything over netconsole and sysrq wasn't working, but I think I'm
>  > going to leave it disabled. Swap on disk is more than fast enough for
>  > buffer/cache and hibernation/resume on my system.
>  
>  
>  I don't know why you had problems with it, but it's working on fine on 
>  every system I've tried it on.  It's not increasing my CPU usage.  It's 
>  probably actually lower due to less swap thrashing. 
There wasn't any thrashing to begin with. I'm currently using 8.0Mi of  my 8 
GiB of swap. This is most likely the case for most casual users, those not 
compiling complex software on their system. This is with Firefox, 
Konversation, KMail, virt-manager and a few Konsole sessions open.

>  > I don't know why people seem to be repeating what seems to
> be the result
>  > of a placebo, saying that their system "feels more responsive" with swap
>  > on zram. People seem to be forgetting why swap on zram came up to begin
>  > with, it has nothing to do with system "responsiveness", which wasn't
> an
>  > issue. It had to do with dealing with OOM. Swap on zram isn't even a
>  > solution to that, it just changes how specifically it affects systems.
>  
>  
>  See, this is a clear indication that you don't understand what it is 
>  doing and weren't listening to the various people trying to explain it. 
>  It is definitely not a placebo.  I gave zram 5G out of the 12G I have 
>  and my laptop is performing way better now.  It's not thrashing the disk 
>  (SSD) every time I switch desktops or windows.  Due to the number and 
>  size of applications I'm running, I normally have to close Thunderbird 
>  when I want to run Chrome.  But now I can start Chrome up with no 
>  problem.  I converted my running system with no reboots and I didn't 
>  change anything else about how I'm using the laptop.
>  
>  # zramctl
>  NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
>  /dev/zram0 lz4             5G   5G  1.7G  1.8G       4
>  
>  5GB of swap space that normally would be on disk is now taking less than 
>  2G of RAM.  Instead of the usual 6G in the disk swap, now I have less 
>  than 2.
>  
>  
>  > For servers, swap is useful regardless of the amount of RAM. Swap is very
>  > nice for use as buffer/cache, and leaves space in RAM for whatever the
>  > server is running. For example, I always configure a 4 GiB swap partition
>  > on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128
>  > GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a
>  > bit different depending on the workload, but it sets a very nice starting
>  > point.
>  
>  Swap is never used as buffer or cache, that doesn't even make sense. 
>  Buffer is storing data before writing it to disk and cache is keeping 
>  hot data somewhere with fast access.  Why do you use so much swap on 
>  your servers?  The linear correlation with RAM is an obsolete idea and 
>  was only somewhat valid when memory sizes were smaller.  If you're using 
>  any significant fraction of that swap space, your server is in trouble. 
It's not used for kernel buffer/cache, that's correct.

-- 
John M. Harris, Jr.

[Samuel Sieb]

On 6/6/20 9:04 AM, Richard W.M. Jones wrote:
>  On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote:
> > This laptop with 8GiB RAM is running two VMs at the same time: Windows
> > 10 and Fedora Workstation 32. The host is Fedora Workstation 32.
>  
>  So this suggests another interesting question: If I have Fedora
>  virtual machines running on a Fedora host, and both are using zram,
>  could there be some negative interaction?  ie. With the pages not
>  being compressible twice.  I suppose (without looking at the source)
>  that zram will skip compressing a page if the compressed page is not
>  any smaller? 
I considered this as well.  But that would only be a concern if the live 
memory of the VM is getting swapped out.  Is that something that could 
happen?

[Samuel Sieb]

On 6/6/20 10:41 AM, John M. Harris Jr wrote:
>  On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote:
> > On 6/6/20 12:42 AM, John M. Harris Jr wrote:
> >
> >> On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM,
> >> enabling swap on zram led to increased CPU usage (Always above 13% where
> >> normally idling at 6%!), and my entire system freezing after about 30
> >> minutes. In all fairness, I don't know why my system froze, as I
> couldn't
> >> get anything over netconsole and sysrq wasn't working, but I think I'm
> >> going to leave it disabled. Swap on disk is more than fast enough for
> >> buffer/cache and hibernation/resume on my system.
> >
> >
> > I don't know why you had problems with it, but it's working on fine on
> > every system I've tried it on.  It's not increasing my CPU usage.  It's
> > probably actually lower due to less swap thrashing.
>  
>  There wasn't any thrashing to begin with. I'm currently using 8.0Mi of  my 8
>  GiB of swap. This is most likely the case for most casual users, those not
>  compiling complex software on their system. This is with Firefox,
>  Konversation, KMail, virt-manager and a few Konsole sessions open. 
Great, then it probably wouldn't benefit you, but it also would not harm 
you at all either.  In my case, my laptop was constantly thrashing the 
swap and now it isn't, so I'm very happy about it.

[Samuel Sieb]

On 6/6/20 9:27 AM, Richard W.M. Jones wrote:
>  On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote:
> > See, this is a clear indication that you don't understand what it is
> > doing and weren't listening to the various people trying to explain
> > it.
>  
>  Not sure this is needed.  The conversation so far has talked about
>  many interesting topics which aren't covered in the proposal, and I
>  value the opinions of people running server / other desktop loads. 
Sure, but the problem is that he keeps making incorrect claims about it 
and saying how bad it is and that it shouldn't be used even though 
multiple people have repeatedly explained that it doesn't work the way 
he thinks it does.

Overall, this has been a great thread.  I've now learned how zram works, 
I've tried it out, and I won't be turning it off. :-)

[Chris Murphy]

On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  But let's say we also add a lower priority disk swap, then my next
>  question ...
>
>  > > 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?
>
>  ... means: Does this secondary swap partition (on disk) contain
>  swapped out zram pages?  Or uncompressed pages?  (Or maybe the
>  question just makes no sense, I don't really know.) 
(ZRAM)
Compression is intrinsic to just the /dev/zram device. The swap code
doesn't share pages between swap devices. The higher priority device
is favored first until full. Once full, pages don't go through the
zram module, thus are not compressed, on their way to the
swap-on-disk.

(ZSWAP)
So yeah, the swap-on-disk scenario might be better suited to a
generator that could use zswap instead, which uses an existing swap
partition and adds a write back cache (zpool) rather than a separate
device. I'm pretty sure (not 100%) that cached page are decompressed
on their way to the swap device. Also, the zpool memory cache is
preallocated, unlike zram devices.

(I am not going to envy any who decide to implement zswap on a system
with ZFS. Wait wait wait, which zpool are you talking about?!)


>  > > 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.
>
>  Interesting, thanks.  It looks like zstd is an alternative, although I
>  don't know which will be better/faster.
>
>  Rich.
>
>  --
>  Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>  Read my programming and virtualization blog: http://rwmj.wordpress.com
>  virt-top is 'top' for virtual machines.  Tiny program with many
>  powerful monitoring features, net stats, disk stats, logging, etc.
>  http://people.redhat.com/~rjones/virt-top
>  _______________________________________________
>  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/[e-mail] 


-- 
Chris Murphy

[Chris Murphy]

On Sat, Jun 6, 2020 at 10:04 AM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote:
>  > This laptop with 8GiB RAM is running two VMs at the same time: Windows
>  > 10 and Fedora Workstation 32. The host is Fedora Workstation 32.
>
>  So this suggests another interesting question: If I have Fedora
>  virtual machines running on a Fedora host, and both are using zram,
>  could there be some negative interaction?  ie. With the pages not
>  being compressible twice.  I suppose (without looking at the source)
>  that zram will skip compressing a page if the compressed page is not
>  any smaller? 
I've not seen a negative interaction. But I am not a scientific sample :D

However, it's surely true that compressed pages in the guest VM
"memory" would not compress again in the host if those same pages are
subject to eviction. Thus, two consequences:

- the host 'zramctl' statistics will show lower compression ratio, as
this type of eviction happens.

- it might be an example workload where the host is better off with
zswap, which is intended to work with swap-on-drive. (not part of this
proposal).

But also the zram devices are still pretty small so the negative
effects are limited. Of course this gets tricky anytime there's
significant overcommit of memory no matter the swap scheme.


-- 
Chris Murphy

[Chris Murphy]

On Sat, Jun 6, 2020 at 4:18 AM David Kaufmann <astra(a)ionic.at&gt; wrote:
>  Hi!
>
>  On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote:
>  > 5GB of swap space that normally would be on disk is now taking less than 2G
>  > of RAM.  Instead of the usual 6G in the disk swap, now I have less than 2.
>
>  What's bugging me about this thread is that quite a few people made
>  comparisions resulting in "compressed zram is smaller than uncompressed
>  disk swap". For me this seems quite obvious, and looks like flawed
>  testing.
>
>  Wouldn't it be more correct to also compress disk swap to compare size?
>  This would probably make the size-argument void, as I'd expect them to
>  be the same size. If it's not, that would be an useful data point.
>  Also I don't care about 10GB stuff sitting in disk swap, whilst 1GB of
>  RAM could be quite essential. This leaves overall performance as a
>  potential benefit of zram swap. 
To me this sounds like too much dependency on swap. There is a
balance. You really do want some swap, because incidental and
occasional heavy swap, is merely inactive page eviction and it's good
to get them out of the way because it frees memory for real work. And
it avoids reclaim, which is what must happen in the noswap case. What
people hate is slow swap. So the proposal is basically: let's use some
fast swap and not a lot of slow swap. It's mainly an optimization.

I expect special workloads will need to make adjustments, and in the
case of heavy persistent swap it might be zswap is better or it might
be that nothing can help that workload except buying more RAM.


>  What almost noone wrote about is CPU usage, for which I saw two
>  anecdotal references: "no change" and "doubled CPU usage". 
For sure there is an impact on CPU. This exchanges IO bound work, for
CPU and memory bound work. But it's pretty lightweight compression.

And again, whatever is defined as "too much" CPU hit for the workload,
necessarily translates into either "suffer the cost of IO bound
swap-on-drive, or suffer the cost of more memory." There is no free
lunch. It really isn't magic.

One thing this might alter the calculus of is swappiness. Because the
zram device is so much faster, page out page in is a lower penalty
than file reclaim reads. So now instead of folks thinking swappiness
should be 1 (or even 0), it's the opposite. It probably should be 100.

See the swappiness section in the Chris Down article referenced in the proposal:
https://chrisdown.name/2018/01/02/in-defence-of-swap.html


>  It would be interesting to see a comparison of swap, compressed swap and
>  zram swap performance while having processes competing on swap.
>  E.g. System with 8 GB RAM:
>  * 2 processes with 3.5 GB memory each
>    this would leave about 1GB for the system itself, so with disk swap
>    there should be not much swapping and with zram swap I'd expect little
>    swapping too.
>  * 2 processes with 4 GB memory each
>    this would force light disk swap usage in the first two cases, I'm not
>    really sure what it would do to zram swap.
>  * 2 processes with 4.5 GB memory each
>    this would definitely lead to constant swapping, but it should still
>    fit in zram swap, with a ratio of 2:1 it should theoretically fit in a
>    2GB zram device, and realistically in a 4GB zram device. 
I'm not sure. Maybe. But this is the plus of having it available and
folks testing it. It is still as rudimentary as swap. It might be
useful to make it a bit smarter, look into some of the cgroupsv2
resource control work for hints on how to make the zram device bigger
or smaller. Some workloads might favor a zram device sized to 100%
RAM, without difficulty.



>  For the programs I'd think of something allocating memory and
>  writing/reading random parts of it, running for N iterations.
>  Interesting points would be: average CPU usage and wallclock time for
>  each of the processes.
>
>  I've left out the obvious cases of "not enough memory usage to use any
>  of those anyway" and "too much memory usage that it results in oom".
>  oom killer should not invoke in daily usage anyway, I see that as a sign
>  for "something has gone seriously wrong", comparable with "program
>  segfaults on start". 
There are worse things than OOM. Stuck with a totally unresponsive
system and no OOM on the way. Hence earlyoom. And on-going resource
control work with cgroupsv2 isolation.



-- 
Chris Murphy

[John M. Harris Jr]

On Saturday, June 6, 2020 3:55:42 PM MST Chris Murphy wrote:
>  On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones
> <rjones(a)redhat.com&gt;
>  wrote:
>  >
>  >
>  > But let's say we also add a lower priority disk swap, then my next
>  > question ...
>  >
>  >
>  >
>  > > > 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?
>  >
>  >
>  >
>  > ... means: Does this secondary swap partition (on disk) contain
>  > swapped out zram pages?  Or uncompressed pages?  (Or maybe the
>  > question just makes no sense, I don't really know.)
>
>
>  (ZRAM)
>  Compression is intrinsic to just the /dev/zram device. The swap code
>  doesn't share pages between swap devices. The higher priority device
>  is favored first until full. Once full, pages don't go through the
>  zram module, thus are not compressed, on their way to the
>  swap-on-disk.
>
>  (ZSWAP)
>  So yeah, the swap-on-disk scenario might be better suited to a
>  generator that could use zswap instead, which uses an existing swap
>  partition and adds a write back cache (zpool) rather than a separate
>  device. I'm pretty sure (not 100%) that cached page are decompressed
>  on their way to the swap device. Also, the zpool memory cache is
>  preallocated, unlike zram devices.
>
>  (I am not going to envy any who decide to implement zswap on a system
>  with ZFS. Wait wait wait, which zpool are you talking about?!) 
Which zswap are you talking about? 

Swap on compressed zvol has been called zswap at times. ;)

- -
John M. Harris, Jr.

[John M. Harris Jr]

On Saturday, June 6, 2020 3:16:02 PM MST Samuel Sieb wrote:
>  On 6/6/20 10:41 AM, John M. Harris Jr wrote:
>  
>  > On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote:
>  > 
>  >> On 6/6/20 12:42 AM, John M. Harris Jr wrote:
>  >>
>  >>
>  >>
>  >>> On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM,
>  >>> enabling swap on zram led to increased CPU usage (Always above 13%
>  >>> where
>  >>> normally idling at 6%!), and my entire system freezing after about 30
>  >>> minutes. In all fairness, I don't know why my system froze, as I
>  >>> couldn't
>  >>> get anything over netconsole and sysrq wasn't working, but I think
> I'm
>  >>> going to leave it disabled. Swap on disk is more than fast enough for
>  >>> buffer/cache and hibernation/resume on my system.
>  >>
>  >>
>  >>
>  >>
>  >> I don't know why you had problems with it, but it's working on fine on
>  >> every system I've tried it on.  It's not increasing my CPU usage. 
> It's
>  >> probably actually lower due to less swap thrashing.
>  > 
>  > 
>  > There wasn't any thrashing to begin with. I'm currently using 8.0Mi of  my
>  > 8 GiB of swap. This is most likely the case for most casual users, those
>  > not compiling complex software on their system. This is with Firefox,
>  > Konversation, KMail, virt-manager and a few Konsole sessions open.
>  
>  Great, then it probably wouldn't benefit you, but it also would not harm 
>  you at all either.  In my case, my laptop was constantly thrashing the 
>  swap and now it isn't, so I'm very happy about it. 
What was causing it to be constantly thrashing? Instead of breaking 
traditional systems even further, and ignoring the users' choice during 
upgrade, why don't we address the actual cause of the problem that some seem 
to have which led to the suggestion of using zram?

-- 
John M. Harris, Jr.

[Samuel Sieb]

On 6/6/20 4:55 PM, John M. Harris Jr wrote:
>  On Saturday, June 6, 2020 3:16:02 PM MST Samuel Sieb wrote:
> > Great, then it probably wouldn't benefit you, but it also would not harm
> > you at all either.  In my case, my laptop was constantly thrashing the
> > swap and now it isn't, so I'm very happy about it.
>  
>  What was causing it to be constantly thrashing? Instead of breaking
>  traditional systems even further, and ignoring the users' choice during
>  upgrade, why don't we address the actual cause of the problem that some seem
>  to have which led to the suggestion of using zram? 
There you go with the "breaking" thing again.  Nothing is getting 
broken!  If you don't need to use the swap, then you won't even notice 
it.  The only "problem" zram is solving is that disk swap is very slow 
so if you can keep the swap in ram, everything stays much faster.

The cause of thrashing in my case is running several memory heavy 
applications.  I have almost 50 Firefox windows with multiple tabs in 
each one, so likely 300 tabs open.  Multi-process Firefox is very nice 
but it makes it difficult to get a good memory usage number, but it's 
probably over 6GB.  I have a very large Inbox and many folders which 
probably contributes to Thunderbird often going to 2 or 3GB.  I'm 
running Discord and various other applications.  Did you read the 
article that Chris posted earlier?  You're always going to want swap, so 
why not start with the very effective zram swap.  It's probably all 
you'll need, but you can add some disk swap as well for any overflow.

[Luya Tshimbalanga]

Tested on HP Envy x360 Convertible Ryzen 2500u with 16 GB RAM and 1TB 
SSD on Fedora 32 Design Suite.

Following the procedure to install zram-generator setting memory 
allocation to 0.50 (or 50%) and commenting out "resume=UUID" line on 
fstab and kernel parameter on boot via grubby, the allocated 14 GB RAM 
Swap partition from the installer is deleted.

zram-swap service is manually disabled via systemctl so the system only 
use zram service.

After reboot here is the observation

--

zram-setup(a)zram0.service - Setup zram based device zram0
      Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; 
static; vendor preset: disabled)
      Active: active (exited) since Sun 2020-06-07 10:11:20 PDT; 1h 
31min ago
     Process: 809 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR > 
/sys/class/block/zram0/max_comp_streams (code=exited, status=0/SUCCESS)
     Process: 813 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE > 
/sys/class/block/zram0/disksize (code=exited, status=1/FAILURE)
     Process: 815 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] &&
mkswap 
/dev/zram0 && swapon /dev/zram0 (code=exited, status=1/FAILURE)
    Main PID: 815 (code=exited, status=1/FAILURE)
         CPU: 9ms
--

I  don't know the cause of failure on the process although the zram0 
seems ok. I would like a pointer to address those minor issues.

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

swapon
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition 7.3G   0B   -2


Is "resume=UUID" necessary for the boot parameter? I removed it as it 
cause longer delay on boot and the swap partition is deleted.

I noticed a more responsive system compared with the traditional setting 
with swap partition. Suspend is working as intended despite a slight 
flashing display on resume (which could be from the driver i.e. amdgpu 
in this case).

Overall, the proposal makes sense with the real test done on both ARM 
devices like Android and Chromebook in addition of Anacona. It will be 
great to get accepted.

-- 
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

[David Kaufmann]

On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote:
>  To me this sounds like too much dependency on swap. 
That's not what I meant, I wanted to emphasize the different values of
disk storage vs. RAM. As said in another email it doesn't matter at all
if there is 0% or 90% of disk swap usage, while RAM usage can be quite
essential. (This is in case swapped out stuff stays swapped out.)

>  What people hate is slow swap. 
This is not generally true, only if RAM gets so tight that applications
start competing for swap.
This is why I've proposed test cases testing exactly that, as for
the case of persistent swap I'd expect the outcome to be a clear win for
disk swap. (Although this can in some cases also be seen as bug, as this
would be applications not really using the allocated space)

>  For sure there is an impact on CPU. This exchanges IO bound work,
> for
>  CPU and memory bound work. But it's pretty lightweight compression.
>  
>  And again, whatever is defined as "too much" CPU hit for the workload,
>  necessarily translates into either "suffer the cost of IO bound
>  swap-on-drive, or suffer the cost of more memory." There is no free
>  lunch. It really isn't magic. 
Yes, that seems obvious to me. What would be interesting is the point,
where one is significantly slower than the other one.
The theoretical testcase is writing data to memory and reading it again.
For this case I'm assuming 8G RAM as total memory.

Until about 95% mem usage I'd expect the disk swap case to win, as it
should behave the same as no swap (with matching swappiness values)

At 150% memory usage assuming a 2:1 compression ratio this would mean:
- disk swap:
  has to write 4G to disk initially, and for reading swap another 4G
  (12G total traffic - 4G initial, 4G swapping out and 4G swapping in)
- zram, assuming 4G zram swap:
  has to write 8G to zram initially, and for reading the data swap 16G
  (24G total traffic - 8G initial, 8G swapping out and 8G swapping in)

It would be good to see actual numbers for this, so far I've only
seen praises on how well the compression ratio is. (Plus the anecdotal
references from a few people)
But this should also be tested with actual CPUs and disks. zram is
obviously faster, but at which point is the overhead from compression,
the reduced unswapped memory and the doubled number of swapping operations
starting to be smaller than the overhead from SSD read/write speed?
Is this almost immediately the case or is this only closely before being
OOM anyway?
The "too much CPU" limit would be the actual wallclock time testprograms
take without hitting OOM. If a program using 120% memory takes 90
seconds to complete its run with swap, and 60 seconds with zram swap,
that would be an improvement. If it's 120 seconds the most likely issue
is "too much CPU used for compression or swapping".

>  One thing this might alter the calculus of is swappiness. Because
> the
>  zram device is so much faster, page out page in is a lower penalty
>  than file reclaim reads. So now instead of folks thinking swappiness
>  should be 1 (or even 0), it's the opposite. It probably should be 100.
>  
>  See the swappiness section in the Chris Down article referenced in the proposal:
>  https://chrisdown.name/2018/01/02/in-defence-of-swap.html 
This article states that setting swappiness to 100 could already be
working fine on SSDs. But yes, swappiness definitely has an influence on
this. I assume testing the edgecases (something around 2 and something
around 100) should be enough.

>  There are worse things than OOM. Stuck with a totally unresponsive
>  system and no OOM on the way. Hence earlyoom. And on-going resource
>  control work with cgroupsv2 isolation. 
This is true boxes where the offending processes are not under manual
control, where it's better that any exploding program is being
terminated as soon as possible.

It's exactly the other way round for manual controlled processes, as a
slowdown before getting to OOM is sometimes enough to be able to decide
what to free up/terminate, before OOM-Killer just goes in brute-force.
That doesn't work too well nowadays, as quite often the swap on disk
fills too fast on SSDs before I've got time to kill something.

Usecase: I've got two browsers running, and I'm working in something
memory intensive in one of them. When experiencing slowdown I'd like to
kill the other one, and not terminate the more memory hungry where I'm
currently working at.

All the best,
David

[Chris Murphy]

On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga <luya(a)fedoraproject.org&gt; wrote:
>  Tested on HP Envy x360 Convertible Ryzen 2500u with 16 GB RAM and 1TB
>  SSD on Fedora 32 Design Suite.
>
>  Following the procedure to install zram-generator setting memory
>  allocation to 0.50 (or 50%) and commenting out "resume=UUID" line on
>  fstab and kernel parameter on boot via grubby, the allocated 14 GB RAM
>  Swap partition from the installer is deleted.
>
>  zram-swap service is manually disabled via systemctl so the system only
>  use zram service. 
zram-generator has no service unit file at all. The zram.service unit
file is part of Anaconda.


>  After reboot here is the observation
>
>  --
>
>  zram-setup(a)zram0.service - Setup zram based device zram0
>        Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service;
>  static; vendor preset: disabled)
>        Active: active (exited) since Sun 2020-06-07 10:11:20 PDT; 1h
>  31min ago
>       Process: 809 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR >
>  /sys/class/block/zram0/max_comp_streams (code=exited, status=0/SUCCESS)
>       Process: 813 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE >
>  /sys/class/block/zram0/disksize (code=exited, status=1/FAILURE)
>       Process: 815 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] &&
> mkswap
>  /dev/zram0 && swapon /dev/zram0 (code=exited, status=1/FAILURE)
>      Main PID: 815 (code=exited, status=1/FAILURE)
>           CPU: 9ms 
I'm not sure whose service this is but I don't have it.

This service is not permanent it's created by the generator, and is
the only service unit I see.
Jun 03 00:47:53 flap.local systemd[1]: swap-create(a)zram0.service: Succeeded.



>  I  don't know the cause of failure on the process although the
> zram0
>  seems ok. I would like a pointer to address those minor issues. 
Conflicting implementations. I recommend removing both anaconda and
zram packages. Keep zram-generator package.

>  zramctl
>  NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
>  /dev/zram0 lzo-rle       7.3G   4K   74B   12K       8 [SWAP]
>
>  swapon
>  NAME       TYPE      SIZE USED PRIO
>  /dev/zram0 partition 7.3G   0B   -2 
Looks good.




>  Is "resume=UUID" necessary for the boot parameter? I
> removed it as it
>  cause longer delay on boot and the swap partition is deleted. 
It's no longer needed. This is a hibernation hint. If you have no need
for hibernation, you can remove it. If you have disabled/removed the
disk based swap partition/LV then you can also remove this resume
hint, because you can't hibernate anyway.


>  I noticed a more responsive system compared with the traditional
> setting
>  with swap partition. Suspend is working as intended despite a slight
>  flashing display on resume (which could be from the driver i.e. amdgpu
>  in this case).
>
>  Overall, the proposal makes sense with the real test done on both ARM
>  devices like Android and Chromebook in addition of Anacona. It will be
>  great to get accepted. 
Cool!



-- 
Chris Murphy

[Chris Murphy]

On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann <astra(a)ionic.at&gt; wrote:
>  On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote:
>  > To me this sounds like too much dependency on swap.
>
>  That's not what I meant, I wanted to emphasize the different values of
>  disk storage vs. RAM. As said in another email it doesn't matter at all
>  if there is 0% or 90% of disk swap usage, while RAM usage can be quite
>  essential. (This is in case swapped out stuff stays swapped out.) 
Inactive pages that are evicted long term, is a workload that I think
would benefit from zswap instead. In that case you get the benefit of
the memory cache for recently used anonymous pages that would
otherwise result in "swap thrashing" and the "least recently used"
pages are moved to disk based swap.

The inherent difficulty with optimizations, is trying to find a
generic approach that helps most use cases. Is this a 100% winner? I
doubt it. Is it an 80% winner across all of Fedora? I think it's at
least that but sure, I can't prove it empirically. There's quite a lot
of evidence it's sane considering all the use cases it's already been
used in.


>  > What people hate is slow swap.
>
>  This is not generally true, only if RAM gets so tight that applications
>  start competing for swap.
>  This is why I've proposed test cases testing exactly that, as for
>  the case of persistent swap I'd expect the outcome to be a clear win for
>  disk swap. (Although this can in some cases also be seen as bug, as this
>  would be applications not really using the allocated space) 
I don't follow this. Where are the proposed test cases? And also in
what case are you saying disk swap is a clear win? Because I would
consider such an example an optimization for that specific edge case,
rather than a generic solution. We've had that as a generic solution
for a while and it's causing some grief for folks where there is
memory competition among applications and those pages need to be
evicted and then not long after paged in - which causes the swap
thrashing effect.

Arguably they need more memory for their workload. But that's in
effect what the feature does. It gives them more bandwidth for
frequently used anonymous pages being paged in and out via compressed
memory rather than significantly slower disk swap.

Is this free? Well, it's free in that it's not out of pocket cost for
more RAM. Instead it exchanges some CPU to make extra room in existing
memory and not have the explosively high latency of disk swap give
them a bad experience.



>  > For sure there is an impact on CPU. This exchanges IO bound work, for
>  > CPU and memory bound work. But it's pretty lightweight compression.
>  >
>  > And again, whatever is defined as "too much" CPU hit for the workload,
>  > necessarily translates into either "suffer the cost of IO bound
>  > swap-on-drive, or suffer the cost of more memory." There is no free
>  > lunch. It really isn't magic.
>
>  Yes, that seems obvious to me. What would be interesting is the point,
>  where one is significantly slower than the other one.
>  The theoretical testcase is writing data to memory and reading it again.
>  For this case I'm assuming 8G RAM as total memory.
>
>  Until about 95% mem usage I'd expect the disk swap case to win, as it
>  should behave the same as no swap (with matching swappiness values) 
Why would disk based swap win? In this example, where there's been no
page outs, the zram device isn't using any memory. Again, it is not a
preallocation.


>  At 150% memory usage assuming a 2:1 compression ratio this would
> mean:
>  - disk swap:
>    has to write 4G to disk initially, and for reading swap another 4G
>    (12G total traffic - 4G initial, 4G swapping out and 4G swapping in)
>  - zram, assuming 4G zram swap:
>    has to write 8G to zram initially, and for reading the data swap 16G
>    (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) 
swap contains anonymous pages, so I'm not sure what you mean by
initial. Whether these pages are internet or typed in or come from
persistent storage - it's a wash between disk or zram swap so it can
be ignored.

Also I don't understand any of your math,how you start with a 4G zram
swap but have 8G. I think you're confused. The cap of 4GiB is the
device size. The actual amount of RAM it uses will be less due to
compression. The zram device size is not the amount of memory used.
And in no case is there a preallocation of memory unless the zram
device is used. It is easy to get confused, by the way. That was my
default state for days upon first stumbling on this.


>  It would be good to see actual numbers for this, so far I've
> only
>  seen praises on how well the compression ratio is. (Plus the anecdotal
>  references from a few people) 
There's a lot of use cases using this in the real world: Chrome,
Android, Fedora IoT, Fedora ARM spins, most all of openQA VM's doing
Anaconda installation tests are taking advantage of it.



>  But this should also be tested with actual CPUs and disks. 
I've been doing it for a year on four separate systems. I am not a
scientific sample. But this is what I'm able to do.


> zram is
>  obviously faster, but at which point is the overhead from compression,
>  the reduced unswapped memory and the doubled number of swapping operations
>  starting to be smaller than the overhead from SSD read/write speed? 
I have definitely seen behavior that sounds like this. That's the case of:

8G RAM + 8G swaponzram (i.e. 100% sized to RAM)
versus
8G RAM + 8G swap on SSD

And then compile webkitgtk using ninja default, which on my system is
10 jobs. The second one always becomes completely unresponsive and I
do a forced power off at 30 minutes. (I have a few cases of 4+ hour
compiles, none finished, some OOM. I have many, as in over 100, cases
of forced power off varying from 1-30 minutes.)

The first one, with zram, more often than not, ends with OOM inside of
30 minutes. I'd have to dig up hand written logs to see if there's any
pattern how long it takes, I think it's around 10 minutes but human
memory isn't exactly reliable so take this with a grain of salt. A
smaller number of times, the system is in a "CPU+memory" based swap
thrash. Approximately as you describe, it's probably just wedged in
making very slow progress because perhaps up to 1/3 or 1/2 of RAM is
being used for the zram device. And the compile flat out wants more
memory than is available.

This task only succeeds with ~12+G of disk based swap. Which is just
not realistic. It's a clearly overcommitted and thus contrived test.
But I love it and hate it at the same time. More realistic is to not
use defaults, and set the number of jobs manually to 6. And in this
case, zram based swap consistently beats disk based swap. Which makes
sense because pretty much all of the inactive pages are going to be
needed at some point by the compile or they are dropped. Following the
compile there aren't a lot of inactive pages left, and I'm not sure
they're even related to the compile at all.

>  Is this almost immediately the case or is this only closely before
> being
>  OOM anyway?
>  The "too much CPU" limit would be the actual wallclock time testprograms
>  take without hitting OOM. If a program using 120% memory takes 90
>  seconds to complete its run with swap, and 60 seconds with zram swap,
>  that would be an improvement. If it's 120 seconds the most likely issue
>  is "too much CPU used for compression or swapping". 
Sure and I think any person is going to notice this kind of latency
without even wall clock timing it. But anyway I time my compiles using
the time command.


>  > There are worse things than OOM. Stuck with a totally
> unresponsive
>  > system and no OOM on the way. Hence earlyoom. And on-going resource
>  > control work with cgroupsv2 isolation.
>
>  This is true boxes where the offending processes are not under manual
>  control, where it's better that any exploding program is being
>  terminated as soon as possible. 
Even under manual control we've got examples of the GUI becoming
completely stuck. Long threads in devel@ based on this Workstation
working group issue - with the same name. So just search archives for
interactivity. Or maybe webkitgtk.

#98 Better interactivity in low-memory situations
https://pagure.io/fedora-workstation/issue/98


>  It's exactly the other way round for manual controlled processes,
> as a
>  slowdown before getting to OOM is sometimes enough to be able to decide
>  what to free up/terminate, before OOM-Killer just goes in brute-force.
>  That doesn't work too well nowadays, as quite often the swap on disk
>  fills too fast on SSDs before I've got time to kill something. 
earlyoom will kill in such a case even if you can't. It's configurable
and intentionally simplistic, based on memory and swap free
percentage.



-- 
Chris Murphy

[David Kaufmann]

On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote:
> > This is not generally true, only if RAM gets so tight that
> applications
> > start competing for swap.
> > This is why I've proposed test cases testing exactly that, as for
> > the case of persistent swap I'd expect the outcome to be a clear win for
> > disk swap. (Although this can in some cases also be seen as bug, as this
> > would be applications not really using the allocated space)
>  
>  I don't follow this. Where are the proposed test cases? And also in
>  what case are you saying disk swap is a clear win? 
I was referencing the testcases from the email before that, but your
webkitgtk compile might also work for that.
What I described as persistent swap is stuff that gets swapped out and
not swapped back in for hours or days.

> > Until about 95% mem usage I'd expect the disk swap case to
> win, as it
> > should behave the same as no swap (with matching swappiness values)
>  
>  Why would disk based swap win? In this example, where there's been no
>  page outs, the zram device isn't using any memory. Again, it is not a
>  preallocation. 
Yes, its a quite boring example, but I've included it for completeness
as a border case. This is just the few megabytes it needs preallocated,
whilst swap is not in use at all.

> > At 150% memory usage assuming a 2:1 compression ratio this would
> mean:
> > - disk swap:
> >   has to write 4G to disk initially, and for reading swap another 4G
> >   (12G total traffic - 4G initial, 4G swapping out and 4G swapping in)
> > - zram, assuming 4G zram swap:
> >   has to write 8G to zram initially, and for reading the data swap 16G
> >   (24G total traffic - 8G initial, 8G swapping out and 8G swapping in)
>  
>  swap contains anonymous pages, so I'm not sure what you mean by
>  initial. Whether these pages are internet or typed in or come from
>  persistent storage - it's a wash between disk or zram swap so it can
>  be ignored. 
I was calculating it from the viewpoint of data, e.g. paging out a
certain amount of data, and paging it in again. "Initial" would be the
amount of data when paging in.
What is definitely different is that I thought of 1 or 2 processes
eating away memory, but not of many thrashing swap. For those it is
definitely not possible to recover from it once thrashing has started.

>  Also I don't understand any of your math,how you start with a 4G
> zram
>  swap but have 8G. I think you're confused. The cap of 4GiB is the
>  device size. The actual amount of RAM it uses will be less due to
>  compression. The zram device size is not the amount of memory used.
>  And in no case is there a preallocation of memory unless the zram
>  device is used. It is easy to get confused, by the way. That was my
>  default state for days upon first stumbling on this. 
I assumed a 2:1 compression rate, so the zram swap holds 8G of data in a
4G zram device. I've calculated with filling the zram device to the
max, so it will use the full 4G. (the 4G limit was arbitrarily chosen)

>  This task only succeeds with ~12+G of disk based swap. Which is just
>  not realistic. It's a clearly overcommitted and thus contrived test. 
This sounds like it's just failing earlier. But it's still a test case.

>  But I love it and hate it at the same time. More realistic is to not
>  use defaults, and set the number of jobs manually to 6. And in this
>  case, zram based swap consistently beats disk based swap.
>  Which makes sense because pretty much all of the inactive pages are
>  going to be needed at some point by the compile or they are dropped.
>  Following the compile there aren't a lot of inactive pages left, and
>  I'm not sure they're even related to the compile at all. 
Especially for a compile those pages are needed quite soon, so thrashing
occurs earlier too. For this it makes a lot of sense that zram is a big
benefit for it.
When I reached the memory limit my usecase was usually having chrome and
firefox open, with firefox having about 500 open tabs, so most of the
data could stay in swap until I triggered swap in, which is very
different from a compiling.

>  Even under manual control we've got examples of the GUI becoming
>  completely stuck. Long threads in devel@ based on this Workstation
>  working group issue - with the same name. So just search archives for
>  interactivity. Or maybe webkitgtk. 
I'm afraid I've read most of those, I usually read all mails to devel@.
So far it seemed mostly like exceptions, but it might also be a specific
configuration on my systems and this issue is more widespread.

>  earlyoom will kill in such a case even if you can't. It's
> configurable
>  and intentionally simplistic, based on memory and swap free
>  percentage. 
I don't have any experience with it, as I use the time from slowdown
until OOM to try to manage the issue myself, usually successful.
But as mentioned above, I might have a specialized usecase, so my
experience might not reflect the average users' experience.

All the best,
David

[James Cassell]

On Sun, Jun 7, 2020, at 9:30 PM, David Kaufmann wrote:
>  On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote:
>  
>  >> At 150% memory usage assuming a 2:1 compression ratio this would mean:
>  >> - disk swap:
>  >> has to write 4G to disk initially, and for reading swap another 4G
>  >> (12G total traffic - 4G initial, 4G swapping out and 4G swapping in)
>  >> - zram, assuming 4G zram swap:
>  >> has to write 8G to zram initially, and for reading the data swap 16G
>  >> (24G total traffic - 8G initial, 8G swapping out and 8G swapping in)
>  > 
>  > swap contains anonymous pages, so I'm not sure what you mean by
>  > initial. Whether these pages are internet or typed in or come from
>  > persistent storage - it's a wash between disk or zram swap so it can
>  > be ignored.
>  
>  I was calculating it from the viewpoint of data, e.g. paging out a
>  certain amount of data, and paging it in again. "Initial" would be the
>  amount of data when paging in.
>  What is definitely different is that I thought of 1 or 2 processes
>  eating away memory, but not of many thrashing swap. For those it is
>  definitely not possible to recover from it once thrashing has started.
>  
>  > Also I don't understand any of your math,how you start with a 4G zram
>  > swap but have 8G. I think you're confused. The cap of 4GiB is the
>  > device size. The actual amount of RAM it uses will be less due to
>  > compression. The zram device size is not the amount of memory used.
>  > And in no case is there a preallocation of memory unless the zram
>  > device is used. It is easy to get confused, by the way. That was my
>  > default state for days upon first stumbling on this.
>  
>  I assumed a 2:1 compression rate, so the zram swap holds 8G of data in a
>  4G zram device. I've calculated with filling the zram device to the
>  max, so it will use the full 4G. (the 4G limit was arbitrarily chosen)
>   
A 4G zram device is 4G apparent size. The amount of memory it takes will vary based on the
compression, but in no case take more than 4G memory. The max uncompressed data that can
be put in a 4G zram device is 4G of data.

V/r,
James Cassell

[Chris Murphy]

On Sun, Jun 7, 2020 at 7:31 PM David Kaufmann <astra(a)ionic.at&gt; wrote:
>  Yes, its a quite boring example, but I've included it for completeness
>  as a border case. This is just the few megabytes it needs preallocated,
>  whilst swap is not in use at all. 
12KiB when not in use?

$ swapon
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition 3.8G   0B   -2
$ zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.9G   4K   74B   12K       4 [SWAP]
$

 And for the zram module:

zram                   28672  1


>  >> At 150% memory usage assuming a 2:1 compression ratio this would mean:
>  >> - disk swap:
>  >>   has to write 4G to disk initially, and for reading swap another 4G
>  >>   (12G total traffic - 4G initial, 4G swapping out and 4G swapping in)
>  >> - zram, assuming 4G zram swap:
>  >>   has to write 8G to zram initially, and for reading the data swap 16G
>  >>   (24G total traffic - 8G initial, 8G swapping out and 8G swapping in)
>  >
>  > swap contains anonymous pages, so I'm not sure what you mean by
>  > initial. Whether these pages are internet or typed in or come from
>  > persistent storage - it's a wash between disk or zram swap so it can
>  > be ignored.
>
>  I was calculating it from the viewpoint of data, e.g. paging out a
>  certain amount of data, and paging it in again. "Initial" would be the
>  amount of data when paging in.
>  What is definitely different is that I thought of 1 or 2 processes
>  eating away memory, but not of many thrashing swap. For those it is
>  definitely not possible to recover from it once thrashing has started.
>
>  > Also I don't understand any of your math,how you start with a 4G zram
>  > swap but have 8G. I think you're confused. The cap of 4GiB is the
>  > device size. The actual amount of RAM it uses will be less due to
>  > compression. The zram device size is not the amount of memory used.
>  > And in no case is there a preallocation of memory unless the zram
>  > device is used. It is easy to get confused, by the way. That was my
>  > default state for days upon first stumbling on this.
>
>  I assumed a 2:1 compression rate, so the zram swap holds 8G of data in a
>  4G zram device. 
That's not how it works. A /dev/zram0 device size of 4G, means a swap
device size of 4G, and at a 2:1 compression means memory usage is 2G.

If the compression ratio is 1:1, then memory usage is 4G
If the compression ratio is 4:1, then memory usage is 1G


There are more options in sysfs to tweak the behavior of the zram
device, including an option to specifically limit memory use. This is
not used by zram-generator. And I haven't done any testing of it,
because while it could be useful for other applications, I think it
could be bad if there's a hard limit of memory reached before the swap
device is full. I have no idea what kernel behavior is like if swap
claims to be 4G but then just stops accepting writes at 3G. I think it
could mean kernel panic or just bad news. So I haven't gone down this
road.


>  > earlyoom will kill in such a case even if you can't.
> It's configurable
>  > and intentionally simplistic, based on memory and swap free
>  > percentage.
>
>  I don't have any experience with it, as I use the time from slowdown
>  until OOM to try to manage the issue myself, usually successful.
>  But as mentioned above, I might have a specialized usecase, so my
>  experience might not reflect the average users' experience. 
earlyoom is enabled by default in Fedora Workstation 32.


-- 
Chris Murphy

[Luya Tshimbalanga]

>  On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga
> <luya(a)fedoraproject.org&gt; wrote:
>  
>  zram-generator has no service unit file at all. The zram.service unit
>  file is part of Anaconda.
>   
Good to know. I proceed to remove on my desktop which has 32 GB RAM.


>  
>  I'm not sure whose service this is but I don't have it.
>   
After removing both anaconda and zram package, the result is 

systemctl status zram-setup(a)zram0.service 
● zram-setup(a)zram0.service - Setup zram based device zram0
     Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; static; vendor preset:
disabled)
     Active: active (exited) since Sun 2020-06-07 22:08:36 PDT; 4min 57s ago
    Process: 856 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR >
/sys/class/block/zram0/max_comp_streams (code=exited, s>
    Process: 879 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE >
/sys/class/block/zram0/disksize (code=exited, status=1>
    Process: 882 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] &&
mkswap /dev/zram0 && swapon /dev/zram0 (code=exited, st>
   Main PID: 882 (code=exited, status=1/FAILURE)
        CPU: 4ms

It seems the script failed to properly read the last two variables.


>  This service is not permanent it's created by the generator, and
> is
>  the only service unit I see.
>  Jun 03 00:47:53 flap.local systemd[1]: swap-create(a)zram0.service: Succeeded.
>   
I got the same result from the journalctl:
systemd[1]: swap-create(a)zram0.service: Succeeded.


 
>  
>  Conflicting implementations. I recommend removing both anaconda and
>  zram packages. Keep zram-generator package. 
Done but these minor conflicts still remained. Maybe filing a bug related to that issue?

>  
>  It's no longer needed. This is a hibernation hint. If you have no need
>  for hibernation, you can remove it. If you have disabled/removed the
>  disk based swap partition/LV then you can also remove this resume
>  hint, because you can't hibernate anyway.
>   
Done. Hibernation was never used as the system has secure-boot enabled by default

--
Luya Tshimbalanga
Fedora Design Suite maintainer

[Chris Murphy]

On Sun, Jun 7, 2020 at 11:25 PM Luya Tshimbalanga
<luya(a)fedoraproject.org&gt; wrote:
>  > On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga
> <luya(a)fedoraproject.org&gt; wrote:
>  >
>  > zram-generator has no service unit file at all. The zram.service unit
>  > file is part of Anaconda.
>  >
>  Good to know. I proceed to remove on my desktop which has 32 GB RAM.
>
>
>  >
>  > I'm not sure whose service this is but I don't have it.
>  >
>  After removing both anaconda and zram package, the result is
>
>  systemctl status zram-setup(a)zram0.service
>  ● zram-setup(a)zram0.service - Setup zram based device zram0
>       Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; static; vendor preset:
> disabled)
>       Active: active (exited) since Sun 2020-06-07 22:08:36 PDT; 4min 57s ago
>      Process: 856 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR >
> /sys/class/block/zram0/max_comp_streams (code=exited, s>
>      Process: 879 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE >
> /sys/class/block/zram0/disksize (code=exited, status=1>
>      Process: 882 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] &&
> mkswap /dev/zram0 && swapon /dev/zram0 (code=exited, st>
>     Main PID: 882 (code=exited, status=1/FAILURE)
>          CPU: 4ms 
This suggests the mkswap failed which might happen if this device is
already active, and somehow this service is from something else. Maybe
do:

dnf provides /usr/lib/systemd/system/zram-setup@.service

If that doesn't reveal anything, maybe this will reveal something:

journalctl -b | grep 'swap\|zram'


>  Done but these minor conflicts still remained. Maybe filing a bug
> related to that issue? 
Might give a shot on here first. Someone else may run into it, and
look in thread for a fix.



-- 
Chris Murphy

[Kevin Kofler]

Nicolas Mailhot via devel wrote:
>  And Go has all build dependencies in the release where they are used
>  (not like rust, with magic ephemeral rawhide-only packages) 
Ephemeral Rawhide-only packages mean the builds cannot be reproduced in a 
release, which is a clear violation of our packaging guidelines. What if a 
security update is needed? (Yes, I know the language claims to be totally 
secure by design. But that is at most true for a small number of security 
vulnerability classes, such as buffer overflows.) And if the software is 
under the GNU GPL or a similar strong copyleft license, it is also a 
violation of the license.

        Kevin Kofler

[Kevin Kofler]

Igor Raits wrote:
>  Why is it painful? You have all dependencies packaged that follow
>  semver (not like Go) and it is quite easy to build those packages. 
Semver is just a convention on version numbers (and one that, IMHO, is still 
open to human interpretation). It does not solve the problem at hand, which 
is that even the compiler does not provide a stable ABI when it changes 
version (affecting all libraries), let alone the libraries. (Semver only 
says that incompatible API changes should lead to a bump in the front rather 
than the back of the version number. That does not solve the problem that 
incompatibilities happen to begin with. At least not as long as any upstream 
can set any version number they wish at any time they wish.)

The lack of stable ABIs is what prevents building shared libraries in a way 
useful to the distribution. Semver is not relevant there.

>  Another example here could be nodejs, even though it does not link
>  statically it is just PITA to package since ecosystem is just full of
>  very small libraries that do not really like to cooperate so you need
>  to have tens of different versions of a lib in a repo. I consider this
>  much bigger problem than the Rust has in Fedora. 
IMHO, Rust and Go also have this exact same "[many] very small libraries" 
problem. Maybe slightly fewer than Node.js, which really takes it to an 
extreme, but still a lot more than C or C++.

The main issue is that it is too easy to depend on a library in all of 
Node.js, Rust, and Go, because you just have to write one import line, and 
the programming language's tooling will automagically pull the dependency 
from the Internet. This is what leads to dependency explosion. It is also a 
PITA for packaging, because Koji rightfully (for obvious security reasons) 
prevents builds from accessing the Internet. In a language like C or C++, 
the developer thinks twice before adding yet another dependency.

>  We also have Fedora CoreOS that uses
>  https://github.com/coreos/afterburn and
>  https://github.com/coreos/zincati that are written in Rust as well and
>  those are core system utilities. 
The situation there is essentially the same as for rpm-ostree: Those are 
core system utilities for CoreOS only, not for a default Fedora 
installation.

This is yet another decision that makes Fedora CoreOS unattractive to me.

>  I don't think saying "Ditch Python, Ruby, Perl, … from the
> system
>  components" is useful for anyone since you know that it is not going to
>  happen. 
Actually, Ruby and Perl are already undesired in the core system layer, 
because each language interpreter increases the size of all our live images. 
There was an official effort to kick out Perl from the Workstation live 
image years ago, which AFAIK has been fully implemented. And Ruby was never 
used in the core system to begin with.

Python is a different story. There are people who are trying to get rid of 
even that (see, e.g., microdnf), but in the default Fedora, it is probably 
here to stay. I consider that unfortunate, because it is a heavy runtime 
dependency, because it is more error-prone than fully compiled languages 
(only syntax errors are caught at package build time, and even that only if 
bytecode generation is set up correctly, whereas, e.g., type errors, 
deprecation warnings, etc. are all spewed at the end user instead), because 
it is not fully backwards compatible (even a new 3.n+1 release can have 
small incompatibilities, and the transition from 2 to 3 was a huge 
breakage), and because it does not perform as well as natively compiled 
code. But I am not entitled to make this decision.

        Kevin Kofler

[Richard W.M. Jones]

On Sat, Jun 06, 2020 at 03:10:37PM -0700, Samuel Sieb wrote:
>  On 6/6/20 9:04 AM, Richard W.M. Jones wrote:
>  >On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote:
>  >>This laptop with 8GiB RAM is running two VMs at the same time: Windows
>  >>10 and Fedora Workstation 32. The host is Fedora Workstation 32.
>  >
>  >So this suggests another interesting question: If I have Fedora
>  >virtual machines running on a Fedora host, and both are using zram,
>  >could there be some negative interaction?  ie. With the pages not
>  >being compressible twice.  I suppose (without looking at the source)
>  >that zram will skip compressing a page if the compressed page is not
>  >any smaller?
>  
>  I considered this as well.  But that would only be a concern if the
>  live memory of the VM is getting swapped out.  Is that something
>  that could happen? 
That's a good point.  The answer is yes (VMs are just regular
processes).  However usually if that does happen then the end result
isn't great, with potentially huge guest pauses when a guest tries to
run and its memory needs to be swapped back in.  Serious
virtualization hosts will try to ensure that memory is not
overcommitted like this.

KSM (kernel samepage merging) might also be affected.  I wonder if the
same original page content always compresses to exactly the same zram
page?  I'm going to guess not, in which case KSM would be defeated by
zram.  Although personally I've never found KSM does anything.
https://www.linux-kvm.org/page/KSM

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Chris Murphy]

On Sat, Jun 6, 2020 at 4:55 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  Also, the zpool memory cache is
>  preallocated, unlike zram devices. 
Nevermind. This is also dynamic.

"dynamically allocated RAM-based memory pool"
https://www.kernel.org/doc/Documentation/vm/zswap.txt


-- 
Chris Murphy

[Luya Tshimbalanga]

On 2020-06-07 11:29 p.m., Chris Murphy wrote:
>  On Sun, Jun 7, 2020 at 11:25 PM Luya Tshimbalanga
>  <luya(a)fedoraproject.org&gt; wrote:
> >> On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga
> <luya(a)fedoraproject.org&gt; wrote:
> >>
> >> zram-generator has no service unit file at all. The zram.service unit
> >> file is part of Anaconda.
> >>
> > Good to know. I proceed to remove on my desktop which has 32 GB RAM.
> >
> >
> >> I'm not sure whose service this is but I don't have it.
> >>
> > After removing both anaconda and zram package, the result is
> >
> > systemctl status zram-setup(a)zram0.service
> > ● zram-setup(a)zram0.service - Setup zram based device zram0
> >       Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; static; vendor
> preset: disabled)
> >       Active: active (exited) since Sun 2020-06-07 22:08:36 PDT; 4min 57s ago
> >      Process: 856 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR >
> /sys/class/block/zram0/max_comp_streams (code=exited, s>
> >      Process: 879 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE >
> /sys/class/block/zram0/disksize (code=exited, status=1>
> >      Process: 882 ExecStart=/bin/sh -c [ "$SWAP" = "y" ]
> && mkswap /dev/zram0 && swapon /dev/zram0 (code=exited, st>
> >     Main PID: 882 (code=exited, status=1/FAILURE)
> >          CPU: 4ms
>  This suggests the mkswap failed which might happen if this device is
>  already active, and somehow this service is from something else. Maybe
>  do:
>
>  dnf provides /usr/lib/systemd/system/zram-setup@.service
>  
The command revealed udisks2-zram, a module for zram, was the provided 
package. Once removed it, there no more service related to zram after 
reboot. I confirm zram is now active as seem on my laptop.

journalctl --no-hostname -b -o  short-monotonic | grep 'swap\|zram'
[    0.468101] kernel: Spectre V1 : Mitigation: usercopy/swapgs barriers 
and __user pointer sanitization
[    1.395800] kernel: zswap: loaded using pool lzo/zbud
[    1.411736] kernel: Lockdown: swapper/0: hibernation is restricted; 
see man kernel_lockdown.7
[    4.408224] systemd[1]: Created slice system-swap\x2dcreate.slice.
[    4.448207] kernel: zram: Added device: zram0
[    4.399416] systemd-modules-load[592]: Inserted module 'zram'
[    4.614307] systemd[1]: Found device /dev/zram0.
[    4.614638] systemd[1]: Starting Create swap on /dev/zram0...
[    4.992881] kernel: zram0: detected capacity change from 0 to 7838105600
[    4.697841] mkswap[636]: Setting up swapspace version 1, size = 7.3 
GiB (7838101504 bytes)
[    4.697841] mkswap[636]: no label, 
UUID=69e8bc81-6456-470a-be0d-8f3319d11df4
[    4.703285] systemd[1]: swap-create(a)zram0.service: Succeeded.
[    4.704332] systemd[1]: Finished Create swap on /dev/zram0.
[    4.704783] audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=swap-create@zram0 comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[    4.704876] audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=swap-create@zram0 comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[    4.711170] systemd[1]: Activating swap Compressed swap on /dev/zram0...
[    5.066565] kernel: Adding 7654396k swap on /dev/zram0. Priority:-2 
extents:1 across:7654396k SSFS
[    4.749250] systemd[1]: Activated swap Compressed swap on /dev/zram0.
[   10.991487] earlyoom[804]: mem total: 14951 MiB, swap total: 7474 MiB
[   10.991487] earlyoom[804]: sending SIGTERM when mem <= 2.68% and swap 
<= 10.00%,
[   10.991660] earlyoom[804]:         SIGKILL when mem <= 1.34% and swap 
<=  5.00%

Thank you for the helps. I found the process is much easier to do.

-- 
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

[Richard W.M. Jones]

On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote:
>  On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann <astra(a)ionic.at&gt;
> wrote:
>  >
>  > On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote:
>  > > To me this sounds like too much dependency on swap.
>  >
>  > That's not what I meant, I wanted to emphasize the different values of
>  > disk storage vs. RAM. As said in another email it doesn't matter at all
>  > if there is 0% or 90% of disk swap usage, while RAM usage can be quite
>  > essential. (This is in case swapped out stuff stays swapped out.)
>  
>  Inactive pages that are evicted long term, is a workload that I think
>  would benefit from zswap instead. In that case you get the benefit of
>  the memory cache for recently used anonymous pages that would
>  otherwise result in "swap thrashing" and the "least recently used"
>  pages are moved to disk based swap. 
Is this how it works?  Previously it was stated that once a page is
swapped to a particular swap device, that's it.  It would be nice if a
page which has been sitting in zram for a while could be swapped out
to the slower / cheaper / larger disk.

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

[Tomasz Torcz]

On Mon, Jun 08, 2020 at 10:58:12AM +0100, Richard W.M. Jones wrote:
>  On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote:
>  > On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann <astra(a)ionic.at&gt; wrote:
>  > >
>  > > On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote:
>  > > > To me this sounds like too much dependency on swap.
>  > >
>  > > That's not what I meant, I wanted to emphasize the different values of
>  > > disk storage vs. RAM. As said in another email it doesn't matter at all
>  > > if there is 0% or 90% of disk swap usage, while RAM usage can be quite
>  > > essential. (This is in case swapped out stuff stays swapped out.)
>  > 
>  > Inactive pages that are evicted long term, is a workload that I think
>  > would benefit from zswap instead. In that case you get the benefit of
>  > the memory cache for recently used anonymous pages that would
>  > otherwise result in "swap thrashing" and the "least recently
> used"
>  > pages are moved to disk based swap.
>  
>  Is this how it works?  Previously it was stated that once a page is
>  swapped to a particular swap device, that's it.  It would be nice if a
>  page which has been sitting in zram for a while could be swapped out
>  to the slower / cheaper / larger disk. 
  It seems possible:
  https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#wri...

-- 
Tomasz Torcz                 “God, root, what's the difference?”
tomek(a)pipebreaker.pl               “God is more forgiving.”

[Lennart Poettering]

On Sa, 06.06.20 02:19, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  Chris Murphy wrote:
>  > 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.
>
>  Also, why does this have to be a systemd generator? As a user administrating
>  his own systems, I find those to be extremely annoying, because they do
>  stuff behind my back that I never asked to happen and I have to mask them
>  (and/or uninstall them completely) to get rid of the unwanted behavior.
>
>  E.g., the systemd generator that tries to automount partitions not listed in
>  fstab based on their GPT UUIDs is just broken. If I do not have the
>  partition in the fstab, I left it out for a reason (e.g., the swap partition
>  I have on my SSD in case I ever need it, which is normally NOT mounted to
>  avoid wearing out the SSD). So why does systemd want to second-guess me and
>  mount that partition behind my back unless I go out of my way to mask the
>  magic generator? 
Well, if you don#t want that behaviour don't use the partition type
UUIDs from the "discoverable partition spec" for your partitions.

It's how these type uuids are defined:

https://systemd.io/DISCOVERABLE_PARTITIONS/

By using these partition type uuids you basically say: "please
automatically mount me, thank you".

>  So why can this zram feature not be a line in fstab, a parameter
> passed
>  through the kernel CLI, or some other solution that is easily tweakable and
>  that will definitely not affect upgrades of existing installations (unlike
>  yet another systemd generator, if it happens to get installed for whatever
>  reason)? 
I am sorry, but in this day and age I am sure we should default to
stuff that just works, and that means: defaults should apply with
empty or immutable /etc.

By making this a default but list it in a configuration file to work,
you require /etc to be writable or populated, and that just sucks.

>  IMHO, the only systemd generator that should ever mount partitions of
> any
>  kind (including virtual ones such as zram) is the systemd-fstab-generator.
>  If you want more stuff mounted, it should be added to /etc/fstab, that's
>  what that file is for! 
I disagree. We should strive for a system that works with empty /etc/
and if booted that way uses default settings. So that /etc is admin
territory where the admin makes changes from the defaults. Thus, if
zram is something to use by default then it should not be stored in
/etc.

Lennart

--
Lennart Poettering, Berlin

[Konstantin Kharlamov]

>  On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>
>  Already discussed in the 'support hibernation' thread.
>
>  Most laptops today have UEFI Secure Boot enabled by default and
>  therefore hibernation isn't possible. And even when the laptop doesn't
>  have Secure Boot enabled, there's a forest of bugs. It works for some
>  people and not others. It was working for me on one laptop in
>  February, consistently doesn't work now and I haven't gotten a reply
>  yet from upstream about the problem.
>
>
>  I am a fan of zswap too, but it needs deconfliction logic with
>  swap-on-zram. The generator would need to come after the
>  fstab-generator, so that it could know if there is a swap-on-drive
>  partition. From that it could do swap-on-zram if there is no
>  swap-on-drive. And setup zswap if there is (instead of two swap
>  devices). The kernel has support for 32 swap devices, since almost
>  forever.
>
>  I've done enough testing with zswap in all the same conditions I've
>  used zram, that I'm confident this can be implemented with this
>  feature in the F33 time frame. But someone needs to help out with the
>  zram-generator code to teach it how to use zswap. There is a sysfs
>  interface to do it so that's pretty straightforward and I think that's
>  how zram-generator does things now for zram, it's not yet using
>  zramctl for setup.
>
>  I can plan to have supplementary tests for zswap on the test day.
>  Hypothetically zswap is a bit smarter because of the LRU basis it uses
>  to decide what to toss out of the memory cache to the swap-on-drive.
>  Whereas two swaps where /dev/zram0 has higher priority, gets favored
>  until it's full, then uses /dev/swapondrive. But in my testing I
>  haven't been able to prove zswap is better. 
Well, recent articles on LWN mention a spike in interest to hibernation¹, so I'd
expect hibernation to get improved.

And I'm not sure it's fair to rule out hibernation forever because of existing
problems on some hw setups. Windows 10 has by default a thing called "fast
startup" which is AFAIK simply hibernation. If that works for them, I guess we can
make it too?

1: https://lwn.net/Articles/821158/

[Konstantin Kharlamov]

>  On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>
>  (ZRAM)
>  Compression is intrinsic to just the /dev/zram device. The swap code
>  doesn't share pages between swap devices. The higher priority device
>  is favored first until full. Once full, pages don't go through the
>  zram module, thus are not compressed, on their way to the
>  swap-on-disk.
>
>  (ZSWAP)
>  So yeah, the swap-on-disk scenario might be better suited to a
>  generator that could use zswap instead, which uses an existing swap
>  partition and adds a write back cache (zpool) rather than a separate
>  device. I'm pretty sure (not 100%) that cached page are decompressed
>  on their way to the swap device. Also, the zpool memory cache is
>  preallocated, unlike zram devices.
>
>  (I am not going to envy any who decide to implement zswap on a system
>  with ZFS. Wait wait wait, which zpool are you talking about?!) 
So, I am testing ZRAM right now (as per your advice in another thread). All well
so far, however reading this makes me think I gonna stumble upon a point where
ZSRAM will be a better fit.

You see, the idea of ZRAM and ZSWAP is improving low-memory situation. This is
especially relevant for small amount of RAM, like your Raspberry example.

In such situation if you, for example, open a lot of tabs in a browser, you may
easily get to a point where even ZRAM is exhausted. Now, had you additionally a
SWAP device, it would be no problem, the data would simply spill over to SWAP.

Yes, SWAP is slow (well, it is on HDD at least). But consider this: in this
workload , you most likely not gonna touch older of browser tabs for quite some
time, so the slowness won't hurt you.

My point is that we still need disk swap. And if we have disk swap, we'd want to
move into SWAP the most unused memory pages. Which is how it works with
ZSWAP. But not how it works with ZRAM (in which case, as you noted, once it's
full, all new data would simply go past ZRAM into disk SWAP)

---------

Now, I love the idea of using either ZRAM or ZSWAP. But to consider which one of
them do we want, I think we would need to discuss first: do we really want to get
rid of disk swap? Hibernation being discussed somewhere in this thread is another
point. I personally don't like idea of removing disk swap.

[Konstantin Kharlamov]

On Mon, 2020-06-08 at 22:54 +0000, Konstantin Kharlamov wrote:
>  > On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones
>  > <rjones(a)redhat.com&gt; wrote:
>  > 
>  > (ZRAM)
>  > Compression is intrinsic to just the /dev/zram device. The swap
>  > code
>  > doesn't share pages between swap devices. The higher priority
>  > device
>  > is favored first until full. Once full, pages don't go through the
>  > zram module, thus are not compressed, on their way to the
>  > swap-on-disk.
>  > 
>  > (ZSWAP)
>  > So yeah, the swap-on-disk scenario might be better suited to a
>  > generator that could use zswap instead, which uses an existing swap
>  > partition and adds a write back cache (zpool) rather than a
>  > separate
>  > device. I'm pretty sure (not 100%) that cached page are
>  > decompressed
>  > on their way to the swap device. Also, the zpool memory cache is
>  > preallocated, unlike zram devices.
>  > 
>  > (I am not going to envy any who decide to implement zswap on a
>  > system
>  > with ZFS. Wait wait wait, which zpool are you talking about?!)
>  
>  So, I am testing ZRAM right now (as per your advice in another
>  thread). All well
>  so far, however reading this makes me think I gonna stumble upon a
>  point where
>  ZSRAM will be a better fit.
>  
>  You see, the idea of ZRAM and ZSWAP is improving low-memory
>  situation. This is
>  especially relevant for small amount of RAM, like your Raspberry
>  example.
>  
>  In such situation if you, for example, open a lot of tabs in a
>  browser, you may
>  easily get to a point where even ZRAM is exhausted. Now, had you
>  additionally a
>  SWAP device, it would be no problem, the data would simply spill over
>  to SWAP.
>  
>  Yes, SWAP is slow (well, it is on HDD at least). But consider this:
>  in this
>  workload , you most likely not gonna touch older of browser tabs for
>  quite some
>  time, so the slowness won't hurt you.
>  
>  My point is that we still need disk swap. And if we have disk swap,
>  we'd want to
>  move into SWAP the most unused memory pages. Which is how it works
>  with
>  ZSWAP. But not how it works with ZRAM (in which case, as you noted,
>  once it's
>  full, all new data would simply go past ZRAM into disk SWAP)
>  
>  ---------
>  
>  Now, I love the idea of using either ZRAM or ZSWAP. But to consider
>  which one of
>  them do we want, I think we would need to discuss first: do we really
>  want to get
>  rid of disk swap? Hibernation being discussed somewhere in this
>  thread is another
>  point. I personally don't like idea of removing disk swap. 
I should've added: browsing the Internet and watching video/reading
social networks, and perhaps playing some browser games in their spare
time, is a common activity for many people. I.e. the workload mentioned
should be popular enough to take into consideration.

[Kevin Kofler]

Lennart Poettering wrote:
>  Well, if you don#t want that behaviour don't use the partition
> type
>  UUIDs from the "discoverable partition spec" for your partitions.
>  
>  It's how these type uuids are defined:
>  
>  https://systemd.io/DISCOVERABLE_PARTITIONS/
>  
>  By using these partition type uuids you basically say: "please
>  automatically mount me, thank you". 
Uh, no. Any tools that create a partition table will use that UUID if I 
create a swap partition. That's all that UUID really means: "this is a 
GNU/Linux swap partition". You unilaterally redefined it to mean that the 
partition should be automatically mounted even if I deliberately keep it 
commented out in /etc/fstab. That conflicts with the original definition of 
that UUID, which is followed by all the partitioning tools out there.

I have had the systemd-auto-gpt-generator masked on all my systems for years 
(ever since I found out about its existence), and it will remain that way, 
sorry.

I was really angry back when I looked at the KSensors statistics, noticed 
that the swap space was twice as large as expected, and realized that 
systemd has decided to mount my spare swap partition on my SSD behind my 
back and hence been using up my SSD behind my back for months. Thankfully, 
the SSD still works years later, looks like I caught it early enough. (You 
can be glad that you have that warranty disclaimer in the license, in any 
case…) Ever since, systemd-auto-gpt-generator is masked.

IMHO, something that mounts partitions behind my back should not exist to 
begin with.

>  I am sorry, but in this day and age I am sure we should default to
>  stuff that just works, and that means: defaults should apply with
>  empty or immutable /etc.
>
>  By making this a default but list it in a configuration file to work,
>  you require /etc to be writable or populated, and that just sucks. 
I disagree. /etc should be prepopulated by packages and/or the distribution 
installer. Then the directory is left for the local admin to customize.

It makes no sense whatsoever for /etc to be immutable. Being writable is 
part of the definition of /etc.

>  I disagree. We should strive for a system that works with empty
> /etc/
>  and if booted that way uses default settings. 
That is just not going to happen, globally. A lot of applications ship 
default settings in /etc that are not contained in the code, or even differ 
from the hardcoded fallback defaults in the code (also because the Fedora 
defaults may differ from the upstream defaults for various reasons).

It is perfectly valid for a package to install %config or %config(noreplace) 
files to /etc, and you cannot expect the package to work if those files are 
completely missing.

>  So that /etc is admin territory where the admin makes changes from
> the
>  defaults. 
That does not conflict with creating an initial config file that sets up 
zram, either as a %config(noreplace) file in a package, or as an unpackaged 
(or %ghost-ed) file written by Anaconda (or Calamares or whatever you use to 
install the system). A lot of existing distribution defaults work that way.

That config file can also be the existing /etc/fstab, which already works 
exactly that way. IMHO, the fewer places we have mounting things, the 
better. So I want to see ALL default mounts added to /etc/fstab rather than 
to some magic generator or .mount file, also that magic tmpfs.mount. (I see 
no valid reason for that not to simply be a line in /etc/fstab.) Having it 
all in one place makes it much easier for administrators to customize.

>  Thus, if zram is something to use by default then it should not be
> stored
>  in /etc. 
Thus, I think that this is a non-sequitur. There is nothing wrong with 
shipping default settings in /etc. It is much better than hardcoding 
defaults in magic generators somewhere in /usr and requiring users/admins to 
mask them to turn off the features they do not want (which means that they 
have to hunt down where the automagic mounting comes from to begin with, 
which is a huge waste of time for local administrators).

Your argument that /etc/fstab still works is not really valid because it 
only works to add mounts or to replace automagic mounts with some other 
mount, but there is no fstab syntax to actually completely disable the 
automagic (because fstab was designed to be the very place where automatic 
mounts are listed, so why would it have needed a syntax to disable a mount 
coming from elsewhere?), so one has to mask the systemd file doing the 
automagic in systemd instead, it cannot be done from /etc/fstab.

        Kevin Kofler

[John M. Harris Jr]

On Monday, June 8, 2020 5:03:20 PM MST Kevin Kofler wrote:
>  Lennart Poettering wrote:
>  
>  > Well, if you don#t want that behaviour don't use the partition type
>  > UUIDs from the "discoverable partition spec" for your partitions.
>  > 
>  > It's how these type uuids are defined:
>  > 
>  > https://systemd.io/DISCOVERABLE_PARTITIONS/
>  > 
>  > By using these partition type uuids you basically say: "please
>  > automatically mount me, thank you".
>  
>  
>  Uh, no. Any tools that create a partition table will use that UUID if I 
>  create a swap partition. That's all that UUID really means: "this is a 
>  GNU/Linux swap partition". You unilaterally redefined it to mean that the 
>  partition should be automatically mounted even if I deliberately keep it 
>  commented out in /etc/fstab. That conflicts with the original definition of
>   that UUID, which is followed by all the partitioning tools out there. 
>  I have had the systemd-auto-gpt-generator masked on all my systems for years
>   (ever since I found out about its existence), and it will remain that
>  way, sorry.
>  
>  I was really angry back when I looked at the KSensors statistics, noticed 
>  that the swap space was twice as large as expected, and realized that 
>  systemd has decided to mount my spare swap partition on my SSD behind my 
>  back and hence been using up my SSD behind my back for months. Thankfully, 
>  the SSD still works years later, looks like I caught it early enough. (You
>  can be glad that you have that warranty disclaimer in the license, in any
>  case…) Ever since, systemd-auto-gpt-generator is masked. 
I wonder if we could get that masked in Fedora Server and KDE Spin, 
potentially along with homed, userdb, repart (Who in the world thought this 
was a good idea?), resolved, networkd, systemd-xdg-autostart-generator (you've 
got to be kidding with these generators.. that's the DE's job, not the init 
system), systemd-sysusers, systemd-growfs, and an ever growing list of absurd 
things thrown into an init system.

These things are not discoverable at all. This stuff really needs to stop 
trying to guess what the user/sysadmin wants to do.

-- 
John M. Harris, Jr.

[Neal Gompa]

On Tue, Jun 9, 2020 at 12:21 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Monday, June 8, 2020 5:03:20 PM MST Kevin Kofler wrote:
>  > Lennart Poettering wrote:
>  >
>  > > Well, if you don#t want that behaviour don't use the partition type
>  > > UUIDs from the "discoverable partition spec" for your partitions.
>  > >
>  > > It's how these type uuids are defined:
>  > >
>  > > https://systemd.io/DISCOVERABLE_PARTITIONS/
>  > >
>  > > By using these partition type uuids you basically say: "please
>  > > automatically mount me, thank you".
>  >
>  >
>  > Uh, no. Any tools that create a partition table will use that UUID if I
>  > create a swap partition. That's all that UUID really means: "this is a
>  > GNU/Linux swap partition". You unilaterally redefined it to mean that the
>  > partition should be automatically mounted even if I deliberately keep it
>  > commented out in /etc/fstab. That conflicts with the original definition of
>  >  that UUID, which is followed by all the partitioning tools out there.
>  > I have had the systemd-auto-gpt-generator masked on all my systems for years
>  >  (ever since I found out about its existence), and it will remain that
>  > way, sorry.
>  >
>  > I was really angry back when I looked at the KSensors statistics, noticed
>  > that the swap space was twice as large as expected, and realized that
>  > systemd has decided to mount my spare swap partition on my SSD behind my
>  > back and hence been using up my SSD behind my back for months. Thankfully,
>  > the SSD still works years later, looks like I caught it early enough. (You
>  > can be glad that you have that warranty disclaimer in the license, in any
>  > case…) Ever since, systemd-auto-gpt-generator is masked.
>
>  I wonder if we could get that masked in Fedora Server and KDE Spin,
>  potentially along with homed, userdb, repart (Who in the world thought this
>  was a good idea?), resolved, networkd, systemd-xdg-autostart-generator (you've
>  got to be kidding with these generators.. that's the DE's job, not the init
>  system), systemd-sysusers, systemd-growfs, and an ever growing list of absurd
>  things thrown into an init system.
>
>  These things are not discoverable at all. This stuff really needs to stop
>  trying to guess what the user/sysadmin wants to do.
>  
What makes you think the stuff we had before was discoverable? I can
tell you right now that it definitely wasn't. These newer things have
the advantage of coherent documentation, unified interfaces, and
consistent availability across distributions. The amount of effort to
discover and leverage this functionality is dramatically lower than
what it was a decade ago with the older things. It's a lot easier to
not accidentally break things, too!

I would not support rolling back all this functionality, and I
personally heavily use all of this across my servers and desktops.



--
真実はいつも一つ！/ Always, there's only one truth!

[Marius Schwarz]

Am 09.06.20 um 02:03 schrieb Kevin Kofler:
>  I disagree. /etc should be prepopulated by packages and/or the
> distribution 
>  installer. Then the directory is left for the local admin to customize. 
Not to
speak of the fact, that you do not know which defaults are in
place, if they are not visible somewhere
logical placed. And even with systemds default in a config, we had a
very stupid situation where limits have been in place, that were
commented OUT in the default config, but systemd did set them because
they were hardcoded in it. A sane hardcoded default in case /etc broke
somehow is fine, but only as a last resort to boot up a working system
to fix itself.

And ZRAM is one of the tools, that should not be enabled by default
anyway. In a best case scenario it extends memory, but in most cases it
slows it down. With 16GB there isn't even a use-case for it.


best regards,
Marius

[Kevin Kofler]

John M. Harris Jr wrote:
>  I wonder if we could get that masked in Fedora Server and KDE Spin,
>  potentially along with homed, userdb, repart (Who in the world thought
>  this was a good idea?), resolved, networkd,
>  systemd-xdg-autostart-generator (you've got to be kidding with these
>  generators.. that's the DE's job, not the init system), systemd-sysusers,
>  systemd-growfs, and an ever growing list of absurd things thrown into an
>  init system. 
Are all those things enabled in Fedora by default? repart and growfs sound 
particularly scary to me. How do they even decide what partitions they want 
to create or grow? I definitely do not want systemd to mess with my 
partitions, even if it does not delete anything!

>  These things are not discoverable at all. This stuff really needs to
> stop
>  trying to guess what the user/sysadmin wants to do. 
Yes, I think this is going too far lately. I think the first generation of 
systemd modules, where the main idea was replacing ugly shell scripts with 
fast native C code, was a good idea, and systemd initially actually made 
things easier to configure (so I have never understood those systemd 
haters), but these days, the feature creep is adding complexity instead of 
removing it.

This reminds me more and more of that proprietary operating system which 
does lots of complex and controversial things without asking you and where 
you have to hunt down obscure registry keys in an attempt to hopefully stop 
it from doing those things.

        Kevin Kofler

[Neal Gompa]

On Tue, Jun 9, 2020 at 5:25 AM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  John M. Harris Jr wrote:
>  > I wonder if we could get that masked in Fedora Server and KDE Spin,
>  > potentially along with homed, userdb, repart (Who in the world thought
>  > this was a good idea?), resolved, networkd,
>  > systemd-xdg-autostart-generator (you've got to be kidding with these
>  > generators.. that's the DE's job, not the init system), systemd-sysusers,
>  > systemd-growfs, and an ever growing list of absurd things thrown into an
>  > init system.
>
>  Are all those things enabled in Fedora by default? repart and growfs sound
>  particularly scary to me. How do they even decide what partitions they want
>  to create or grow? I definitely do not want systemd to mess with my
>  partitions, even if it does not delete anything!
>  
These modules are used specifically for cloud variants so that on
first boot, we can reconfigure VM images to match the storage setup
requested with cloud-init/ignition. We don't use repart or growfs in
Server Edition or desktop variants.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Lennart Poettering]

On Di, 09.06.20 11:24, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  John M. Harris Jr wrote:
>  > I wonder if we could get that masked in Fedora Server and KDE Spin,
>  > potentially along with homed, userdb, repart (Who in the world thought
>  > this was a good idea?), resolved, networkd,
>  > systemd-xdg-autostart-generator (you've got to be kidding with these
>  > generators.. that's the DE's job, not the init system), systemd-sysusers,
>  > systemd-growfs, and an ever growing list of absurd things thrown into an
>  > init system.
>
>  Are all those things enabled in Fedora by default? repart and growfs sound
>  particularly scary to me. How do they even decide what partitions they want
>  to create or grow? I definitely do not want systemd to mess with my
>  partitions, even if it does not delete anything! 
Here's a novel idea: maybe read up on it, before making such a fuss
about it. You are fud'ing, and you know it.

Hint: they are NOPs if there's no configuration for them.

Lennart

--
Lennart Poettering, Berlin

[Chris Murphy]

On Mon, Jun 8, 2020 at 4:32 PM Konstantin Kharlamov <hi-angel(a)yandex.ru&gt; wrote:
>  Well, recent articles on LWN mention a spike in interest to hibernation¹, so I'd
> expect hibernation to get improved. 
It's a start. They may also want to pick up the encrypted+signed work,
but for different reasons. In the cloud case, they intentionally want
to resume to a VM that is not the same as the origin.

>  And I'm not sure it's fair to rule out hibernation forever
> because of existing problems on some hw setups. Windows 10 has by default a thing called
> "fast startup" which is AFAIK simply hibernation. If that works for them, I
> guess we can make it too? 
My research suggests they have similar problems with ACPI bugs related
to S4; what I don't know is if they have make/model specific work
arounds that improve the reliability. Also, they are more focused on
S0 low power idle, i.e. Modern Standby. Far fewer bugs. There is some
work happening in this area in the linux kernel.


-- 
Chris Murphy

[Chris Murphy]

On Mon, Jun 8, 2020 at 4:54 PM Konstantin Kharlamov <hi-angel(a)yandex.ru&gt; wrote:

>  So, I am testing ZRAM right now (as per your advice in another
> thread). All well
>  so far, however reading this makes me think I gonna stumble upon a point where
>  ZSRAM will be a better fit.
>
>  You see, the idea of ZRAM and ZSWAP is improving low-memory situation. This is
>  especially relevant for small amount of RAM, like your Raspberry example.
>
>  In such situation if you, for example, open a lot of tabs in a browser, you may
>  easily get to a point where even ZRAM is exhausted. Now, had you additionally a
>  SWAP device, it would be no problem, the data would simply spill over to SWAP.
>
>  Yes, SWAP is slow (well, it is on HDD at least). But consider this: in this
>  workload , you most likely not gonna touch older of browser tabs for quite some
>  time, so the slowness won't hurt you. 
SD Cards are pretty slow in Pi's. And also they have much more limited
wear endurance than laptop SSDs. So in this use case for sure, memory
based swap only is idea. If it's not enough, then I think I've reached
the physical limits of the configuration. But how to make this more
dynamic and smarter is certainly an area worth exploration, including
the idea of creating swapfiles on demand. But that is beyond the scope
of this feature change.


>  Now, I love the idea of using either ZRAM or ZSWAP. But to consider
> which one of
>  them do we want, I think we would need to discuss first: do we really want to get
>  rid of disk swap? Hibernation being discussed somewhere in this thread is another
>  point. I personally don't like idea of removing disk swap. 
It is worth continuing the discussion. But for non-hibernation and
incidental swap, taking up more than 4G of swap seems excessive and
only leads to slow systems that will never OOM  until all of the swap
partition is full.


-- 
Chris Murphy

[Samuel Sieb]

On 6/9/20 1:43 AM, Marius Schwarz wrote:
>  And ZRAM is one of the tools, that should not be enabled by default
>  anyway. In a best case scenario it extends memory, but in most cases it
>  slows it down. With 16GB there isn't even a use-case for it. 
It doesn't slow anything down.  If you don't use it, it's only taking up 
a few KB of RAM.  If you do end up needing it, it's there and it saves 
you from slow disk swapping.

[Richard Shaw]

On Tue, Jun 9, 2020 at 3:44 AM Marius Schwarz <fedoradev(a)cloud-foo.de&gt;
wrote:

>  And ZRAM is one of the tools, that should not be enabled by default
>  anyway. In a best case scenario it extends memory, but in most cases it
>  slows it down. With 16GB there isn't even a use-case for it.
>  
I don't think that can be said as absolute. While I have 16GB in my desktop
workstation and pretty much build packages from source and rarely use any
swap, there was one package I couldn't build because of extensive use of
c++ templating. There's no guarantee that having zswap/zram would have made
it possible, but it might have.

Thanks,
Richard

[Konstantin Kharlamov]

On Tue, 2020-06-09 at 09:04 -0600, Chris Murphy wrote:
>  On Mon, Jun 8, 2020 at 4:54 PM Konstantin Kharlamov <
>  hi-angel(a)yandex.ru&gt; wrote:
>  
>  > So, I am testing ZRAM right now (as per your advice in another
>  > thread). All well
>  > so far, however reading this makes me think I gonna stumble upon a
>  > point where
>  > ZSRAM will be a better fit.
>  > 
>  > You see, the idea of ZRAM and ZSWAP is improving low-memory
>  > situation. This is
>  > especially relevant for small amount of RAM, like your Raspberry
>  > example.
>  > 
>  > In such situation if you, for example, open a lot of tabs in a
>  > browser, you may
>  > easily get to a point where even ZRAM is exhausted. Now, had you
>  > additionally a
>  > SWAP device, it would be no problem, the data would simply spill
>  > over to SWAP.
>  > 
>  > Yes, SWAP is slow (well, it is on HDD at least). But consider this:
>  > in this
>  > workload , you most likely not gonna touch older of browser tabs
>  > for quite some
>  > time, so the slowness won't hurt you.
>  
>  SD Cards are pretty slow in Pi's. And also they have much more
>  limited
>  wear endurance than laptop SSDs. So in this use case for sure, memory
>  based swap only is idea. If it's not enough, then I think I've
>  reached
>  the physical limits of the configuration. But how to make this more
>  dynamic and smarter is certainly an area worth exploration, including
>  the idea of creating swapfiles on demand. But that is beyond the
>  scope
>  of this feature change.
>  
>  
>  > Now, I love the idea of using either ZRAM or ZSWAP. But to consider
>  > which one of
>  > them do we want, I think we would need to discuss first: do we
>  > really want to get
>  > rid of disk swap? Hibernation being discussed somewhere in this
>  > thread is another
>  > point. I personally don't like idea of removing disk swap.
>  
>  It is worth continuing the discussion. But for non-hibernation and
>  incidental swap, taking up more than 4G of swap seems excessive and
>  only leads to slow systems that will never OOM  until all of the swap
>  partition is full. 
Btw, how about a compromise: we could use ZRAM for installations
without SWAP partition and ZSRAM in case user decided to add a SWAP
partition?

[John M. Harris Jr]

On Tuesday, June 9, 2020 2:24:02 AM MST Kevin Kofler wrote:
>  John M. Harris Jr wrote:
>  
>  > I wonder if we could get that masked in Fedora Server and KDE Spin,
>  > potentially along with homed, userdb, repart (Who in the world thought
>  > this was a good idea?), resolved, networkd,
>  > systemd-xdg-autostart-generator (you've got to be kidding with these
>  > generators.. that's the DE's job, not the init system), systemd-sysusers,
>  > systemd-growfs, and an ever growing list of absurd things thrown into an
>  > init system.
>  
>  
>  Are all those things enabled in Fedora by default? repart and growfs sound 
>  particularly scary to me. How do they even decide what partitions they want
>  to create or grow? I definitely do not want systemd to mess with my
>  partitions, even if it does not delete anything!
>  
>  
>  > These things are not discoverable at all. This stuff really needs to stop
>  > trying to guess what the user/sysadmin wants to do.
>  
>  
>  Yes, I think this is going too far lately. I think the first generation of 
>  systemd modules, where the main idea was replacing ugly shell scripts with
>  fast native C code, was a good idea, and systemd initially actually made
>  things easier to configure (so I have never understood those systemd
>  haters), but these days, the feature creep is adding complexity instead of
>  removing it. 
I completely agree. For example, I really like systemd as it is in RHEL7. Past 
that, it's an ever growing list of things that have nothing to do with the 
init system. Instead of being a fairly elegant init system, it's got more and 
more cruft thrown in on top.

Contrary to what is repeatedly claimed, these do still run even if there's no 
config, even if they don't do anything, which isn't the case. systemd-homed 
was mounting /home where it was explicitly listed as `noauto` last time I 
checked. See the output of `systemctl status systemd-homed` or `systemctl 
status systemd-repart`. What's even more wild is that you can't easily disable 
it. Even though it's supposed to be disabled ("vendor preset: disabled")
it's 
actually built into systemd, as a static unit.

To quote Lennart on one of these, userdb specifically, "not sure I get this? 
why disable this at all? it's a tiny daemon, and shouldn't matter at all..."

>  This reminds me more and more of that proprietary operating system
> which 
>  does lots of complex and controversial things without asking you and where 
>  you have to hunt down obscure registry keys in an attempt to hopefully stop
>  it from doing those things. 
Agreed on this as well, and that's making life hell for sysadmins and users 
alike.

-- 
John M. Harris, Jr.

[Kevin Kofler]

John M. Harris Jr wrote:
>  What's even more wild is that you can't easily disable it.
> Even though
>  it's supposed to be disabled ("vendor preset: disabled") it's actually
>  built into systemd, as a static unit. 
Have you tried masking the units? Disabling tends to have only limited 
success (because it only disables the unit loading by itself, but not it 
getting loaded by other units), masking is more effective.

        Kevin Kofler

[John M. Harris Jr]

On Wednesday, June 10, 2020 2:50:55 AM MST Kevin Kofler wrote:
>  John M. Harris Jr wrote:
>  
>  > What's even more wild is that you can't easily disable it. Even though
>  > it's supposed to be disabled ("vendor preset: disabled") it's
> actually
>  > built into systemd, as a static unit.
>  
>  
>  Have you tried masking the units? Disabling tends to have only limited 
>  success (because it only disables the unit loading by itself, but not it 
>  getting loaded by other units), masking is more effective. 
I'm aware, and I have had success with masking the ones I've had issues with 
so far.

-- 
John M. Harris, Jr.

[Chris Murphy]

Help needed!

We're discussing the parameters of the test day, and the difficulty is
answering: "what are the test cases?"

This comment and the one after it:
https://pagure.io/fedora-qa/issue/632#comment-658340

What language simply and properly conveys that the "test case" is
essentially created on-the-fly by the user, based on their expectation
of a particular workload they know stresses their system? We aren't
looking for test cases that would blow up the system whether it's
using disk-based or zram-based swap. We want to discover cases where
things work with disk-based swap, but not zram-based swap.

A generic description might be: a workload that you perform that
results in OOM 50% of the time. OK now try that workload using
swap-on-zram, does it succeed or fail more often than 50% of the time?

Thanks!

--
Chris Murphy

[John M. Harris Jr]

On Thursday, June 4, 2020 1:30:07 PM MST Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>  
>  == Summary ==
>  
>  Swap is useful, except when it's slow. zram is a RAM drive that uses
>  compression. Create a swap-on-zram during start-up. And no longer use
>  swap partitions by default.
>  
>  
>  == Owner ==
>  * Name: [[User:chrismurphy| Chris Murphy]]
>  * Email: chrismurphy(a)fedoraproject.org
>  
>  == Detailed Description ==
>  
>  ==== zram Basic function ====
>  
>  The zram† device, typically <span style=color:brown>/dev/zram0</span>,
>  has a size set at create time during early boot, by zram-generator†
>  per its configuration file. The memory used is not preallocated. It's
>  dynamically allocated and deallocated, on demand. Due to compression,
>  a full <span style=color:brown>/dev/zram0</span> uses half as much
>  memory as its size.
>  
>  The <span style=color:brown>/dev/zram0</span> behaves like any other
>  block device. It can be formatted with a file system, or mkswap, which
>  is the intention with this change proposal.
>  
>  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. The
>  zram driver starts to allocate memory at roughly 1/2 the rate of page
>  outs, due to compression. But, there is no free lunch. This means
>  swap-on-zram is not as effective at page eviction as swap-on-drive,
>  the eviction rate is ~50% instead of 100%. But it is at least an order
>  of magnitude faster than drive based swap.
>  
>  zram has about 0.1% overhead or ~1MiB/1GiB. If the workload never
>  touches swap, this overhead is the sole cost. In practice when not
>  used at all, feature owner has experienced ~0.04% overhead.
>  
>  Example: A system has 16 GiB RAM. The proposed defaults suggest the
>  <span style=color:brown>/dev/zram0</span> device will be 4 GiB. If the
>  workload completely fills up swap with 4 GiB of anonymous pages,
>  what's happened? The <span style=color:red>zramctl</span> command will
>  display the true compression ratio. If 2:1 is really obtained, it
>  means 4GiB swap data is compressed to 2GiB. Therefore 2GiB is the
>  actual RAM usage, and is also the net effective eviction. i.e. 4 GiB
>  anonymous pages are evicted, but are then compressed and pinned into 2
>  GiB RAM, for a net memory savings of 2 GiB.
>  
>  †</br >
>  [https://www.kernel.org/doc/Documentation/blockdev/zram.txt kernel.org
>  zram.txt] 
 
>  [https://github.com/systemd/zram-generator Github zram-generator
> project]
>  
>  
>  ==== Overview of the Feature ====
>  
>  Using swap is a good idea†, but no one likes it when it's slow.
>  Anaconda and Fedora IoT have been using swap-on-zram by default for
>  years. This builds on their prior effort.
>  
>  
>  There are three components to the change:
>  
>  # Install systemd rust-zram-generator† package. This does not enable
>  swap-on-zram, it only makes the generator available.</br >
>  # Install a default zram-generator configuration. When present,
>  swap-on-zram is set-up during startup.</br >
>  # Do not create swap partition/LV with default installations.
>  
>  This proposal aims to apply all three, for all Fedora editions and
>  spins, by default.
>  
>  It further aims to apply the first two, for upgrades and custom
>  installations. 
 
>  It might be useful to only make the generator available (1), should
> an
>  edition/spin wish to opt out, or as a fallback if applying the feature
>  to upgrades fails to withstand scrutiny.
>  
>  †</br >
>  There is a tl;dr section at the top. Highly recommend reading the
>  whole article. [https://chrisdown.name/2018/01/02/in-defence-of-swap.html
>  In defence of swap: common misconceptions]
>  
>  
>  ==== Default zram device configuration: ====
>  
>  During startup, create a zram device <span
>  style=color:brown>/dev/zram0</span>, with a size equal to 50% RAM, but
>  capped† to 4 GiB, and with a higher than typical swap priority†.
>  
>  These values seem reasonably conservative, and are based on prior work
>  in Fedora. Anaconda sets swap-on-drive sized to 50% RAM in the no
>  hibernation case, common outside x86. Fedora IoT's implementation also
>  sets swap-on-zram size to 50% RAM.
>  
>  †</br >
>  [https://github.com/systemd/zram-generator/issues/10 RFE: should be
>  able to set a cap on zram device size #10]
>  
>  [https://github.com/systemd/zram-generator/issues/8 RFE: should set priority
>  #8] 
 
>  
>  ==== Default installer behavior  ====
>  
>  The installer is currently responsible for creating a swap-on-drive
>  device. This will be dropped. The zram-generator + configuration file
>  will trigger the setup and activation of swap-on-zram. This means
>  hibernation isn't possible, even on systems that could support it.
>  
>  Please see
>  [https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
>  Supporting hibernation in Workstation edition] for much more detailed
>  information, including why it's increasingly likely hibernation isn't
>  possible anyway, and a path to improving hibernation support.
>  
>  
>  ==== Custom/Advance partitioning installer behavior ====
>  
>  The user can add swap using Custom partitioning at install time. This
>  is swap-on-drive. And the installer will also include the <span
>  style=color:red> resume=UUID </span> kernel parameter for this swap
>  device. No change in behavior here.
>  
>  Since swap-on-zram is still enabled by default, there will be two
>  swaps: swap-on-zram, and swap-on-drive. The swap-on-zram will have
>  higher priority, thus being favored over drive based swap. The kernel
>  is smart enough to know it can't hibernate to a zram device, and will
>  instead use drive based swap.
>  
>  
>  ==== How can it be disabled? ====
>  
>  Immediately:</br >
>  <span style=color:red>swapoff /dev/zram0</span>
>  
>  Permanently:</br >
>  <span style=color:red>rm /etc/systemd/zram-generator.conf</span>
>  
>  
>  == Feedback ==
>  
>  ==== You're enabling it on upgrades? ====
>  
>  That's the current plan. As a technical matter, feature owner is
>  confident this feature will improve the experience of all users
>  regardless of configuration. As a non-technical matter, it's
>  recognized that (a) ''hey pal, you're messing with my customizations,
>  not cool!'' and (b) ''swap always stinks, I don't care if it has a
> 'Z'
>  in the name!'' may need more convincing.
>  
>  There are possible risks.
>  
>  * Workloads that expect full use of memory, and depend on 100% page
>  eviction. These may run slower if they really need full use of memory,
>  but some memory is used for the zram device instead. Such workloads
>  might favor zswap.
>  
>  * Workloads with low compressible pages. In the worst case, this means
>  unnecessary work merely moving pages around.
>  
>  * Workloads with memory full, and hibernation. Hibernation is already
>  stressful to memory-management subsystem and prone to bailing out in
>  such cases. The swap-on-zram will be favored for evictions in the
>  attempt to free memory to create the hibernation image. It could
>  increase instances of hibernation entry failure. This isn't a crash,
>  it just means the attempt doesn't succeed, and the system resumes
>  operation instead of hibernating.
>  
>  While possible, it's difficult to estimate their probability. But this
>  is a significant consideration in the conservative default zram size.
>  Users can easily increase zram size as needed for their use case,
>  simply by editing <span
>  style=color:red>/etc/systemd/zram-generator.conf</span> and the change
>  takes effect at next boot.
>  
>  ==== Why systemd zram-generator? ====
>  
>  It's the most upstream implementation to date, is fast and
>  lightweight. The zram-generator uses existing systemd infrastructure
>  to setup the zram block device, format it as swap, and swapon - all
>  during early boot. It's very similar in behavior to fstab-generator,
>  gpt-auto-generator, and cryptsetup-generator†.
>  
>  Converging on one implementation avoids user confusion. And while the
>  alternatives are nice and work fine, a systemd generator is
>  particularly well suited for this use case compared to a systemd
>  service unit.†
>  
>  Also, it's an reference implementation of a system generator written in
>  Rust. 
 
>  †</br >
>  [https://www.freedesktop.org/software/systemd/man/systemd.generator.html
>  freedesktop.org About systemd generators.]</br >
>  [https://lists.fedoraproject.org/archives/list/[e-mail]
>  /message/TCY534JPIMZ3OXM5Q5E2ZH5PSAKQNGP7/ 
 devel@ ''Re: swap-on-zram by
>  default'' Zbigniew Jędrzejewski-Szmek, systemd
> zram-generator
>  author/maintainer]
>  
>  
>  ==== Why not a bigger zram device? ====
>  
>  The main idea of being conservative is to address concerns about
>  upgrades. It's possible some workloads will have less compressible
>  data. Hence, not going with <span style=color:brown>/dev/zram0</span>
>  sized to 100% of RAM at this time. Even a <span
>  style=color:brown>/dev/zram0</span> of 200% RAM is not unreasonable
>  *if* the compression ratio is at least 2:1. However, it's possible a
>  system can get "stuck" in a kind of swap thrashing similar to
>  conventional swap-on-drive, except it's CPU and memory bound, rather
>  than IO bound. Feature owner thinks it's better to just oom, instead
>  of getting overly aggressive with the zram device size.
>  
>  Conversely it's possible to be too conservative with the size, and
>  result in more instances of OOM kill. If applying the feature to
>  upgrades is rejected, it's probably reasonable to increase the cap to
>  ~8GiB. Of course more feedback and testing is needed, and it will be
>  taken into consideration.
>  
>  Note that the kernel zram doc says an excessively sized zram device
>  does come with overhead. Users's can increase the size easily
>  post-install, a capability they don't easily have with swap-on-drive.
>  The goal for Fedora 33 is a default that's useful and safe for the
>  vast majority of use cases.
>  
>  
>  ==== Why not zswap? ====
>  
>  Zswap† is a similar idea, but with a totally different implementation.
>  It is swap specific, uses a RAM cache, and requires a conventional
>  swap partition existing already. It might be true certain workloads
>  are better suited for using zswap. But swap-on-zram depends only on
>  volatile storage. This is simpler and it's more secure. Whereas zswap
>  "spills over" into swap-on-drive and will leak user data if that swap
>  device isn't encrypted. Some workloads may do better with zswap, and
>  it's a valid future feature for a new generator, or possibly extend
>  zram-generator to support it via the configuration file. Maybe the
>  generator could favor zswap when swap-on-drive already exists; and
>  fallback to swap-on-zram?
>  
>  †</br >
>  [https://www.kernel.org/doc/Documentation/vm/zswap.txt kernel.org
>  zswap.txt] 
 
>  
>  == Benefit to Fedora ==
>  
>  * significantly improves system responsiveness, especially when swap
>  is under pressure;
>  * more secure, user data leaks into swap are on volatile media;
>  * without swap-on-drive, there's better utilization of a limited
>  resource: benefit of swap without the drive space consumption;
>  * complements on-going resource control work, including earlyoom;
>  * further reduces the time to out-of-memory kill, when workloads exceed
>  limits; 
 * improves performance for both "no swap" and "existing
swap"
>  setups; 
>  
>  
>  == Scope ==
>  
>  * Proposal owners:
>  ** add zram-generator package to comps and kickstarts as appropriate
>  ** obsolete zram package (used by Fedora IoT)
>  ** means of per edition/spin configurations, if needed
>  ** coordinate a test day
>  
>  * Other developers:
>  **Anaconda are agreeable to deprecating their built-in implementation
>  in favor of swap-on-zram
>  **RFE's for zram-generator: users are not worse off if they don't
>  happen. Open request for help, to make it possible. It's much
>  appreciated.</br >
>  [https://github.com/systemd/zram-generator/issues/10 RFE: should be
>  able to set a cap on zram device size #10]</br >
>  [https://github.com/systemd/zram-generator/issues/8 RFE: should set priority
>  #8] 
 
>  * Release engineering: [https://pagure.io/releng/issues #9495]
>  
>  * Policies and guidelines: N/A
>  
>  * Trademark approval: N/A
>  
>  
>  == Upgrade/compatibility impact ==
>  
>  Add Supplements:fedora-release-common to zram-generator to pull it in
>  on upgrades.
>  
>  Existing systems without swap will have swap-on-zram enabled.
>  
>  Existing systems with swap-on-drive, will also have swap-on-zram
>  enabled (two swap devices), with higher priority for the zram device.
>  Existing swap-on-drive will not be removed.
>  
>  'zram' package contains zram-swap.service and associated bash scripts,
>  and is currently used by Fedora IoT and ARM spins. It will be
>  obsoleted to avoid conflicting/duplicative swap-on-zram
>  implementations.
>  
>  
>  == How To Test ==
>  
>  Any hardware. Any version of Fedora.
>  
>  # dnf install zram-generator
>  # cp /usr/share/doc/zram-generator/zram-generator.conf.example
>  /etc/systemd/zram-generator.conf
>  # Edit the configuration
>  # Reboot
>  # Check that swap is on a zram device: zramctl, swapon
>  # Detailed check: journalctl -b -o short-monotonic | grep 'swap\|zram'
>  # Check that priority is higher than existing swap if two or more are
>  listed. ## (Enhancement is needed for this.)
>  
>  Suggested configuration file values:</br >
>  <span style=color:red>[zram0]</span></br >
>  <span style=color:red>memory-limit = none</span></br >
>  <span style=color:red>zram-fraction = 0.5</span></br >
>  
>  Feel free to run your usual workloads more aggressively or in
>  parallel. Suspend-to-RAM and suspend-to-drive are expected to continue
>  to work too (or at least hit all the same bugs as without zram being
>  used).
>  
>  Also, you can see the actual compression ratio achieved with the
>  following command:</br >
>  <span style=color:red> zramctl </span>
>  
>  
>  ==== Test Day ====
>  
>  [https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to
>  discover edge cases, and tweak the default configuration if necessary
>  to establish a good one-size-fits all approach.
>  
>  
>  == User Experience ==
>  
>  The user won't notice anything displeasing. If their usual workload
>  causes them to dread swap thrashing, they'll be surprised that
>  thrashing doesn't happen. The user might get curious if they don't
>  find a swap entry in /etc/fstab. Or if they 'swapon' and see swap
>  pointing to <span style=color:brown>/dev/zram0</span> instead of a
>  drive partition or LV.
>  
>  
>  == Dependencies ==
>  
>  N/A
>  
>  
>  == Contingency Plan ==
>  
>  * Contingency mechanism: Don't ship the generator = big hammer, but
>  easy. Preferable to ship the generator, but only selectively ship
>  configuration files = scalpel, pretty easy.
>  * Contingency deadline: Beta freeze
>  * Blocks release? No.
>  * Blocks product? No.
>  
>  
>  == Documentation ==
>  
>  Consider adding a hint in an /etc/fstab comment? There is no man page
>  for this, and the documentation is also minimal, besides what's in
>  this feature proposal. It's an open question how the user should get
>  more information on how to configure and tweak it. But then, they
>  don't have that for swap today either. There's just institutional
>  knowledge.
>  
>  Hence, a strong test day, with a lot of people and press coverage of
>  the feature, might help spread the word for institutional knowledge
>  changes coming.
>  
>  Ideas welcome.
>  
>  
>  == Release Notes ==
>  Pending feedback and test day. 
Jesus Christ, this actually got approved. It's time to fork Fedora. This is 
really getting out of hand.

-- 
John M. Harris, Jr.

[Chris Murphy]

On Sat, Jun 27, 2020 at 11:25 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:

>  Jesus Christ, this actually got approved. It's time to fork
> Fedora. This is
>  really getting out of hand. 
It will not apply to upgrades, just new clean installs. Still pending
discussion with installer team on whether to also use it by default
when users custom partition and manually add a swap partition (and
test day).

Maybe circle back on the upgrades question (and others about zswap)
for Fedora 34.


-- 
Chris Murphy

[Matthew Miller]

On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
>  Jesus Christ, this actually got approved. It's time to fork
> Fedora. This is 
>  really getting out of hand. 

As mentioned earlier, there's no need to "fork Fedora". It sounds like
there
are at least of few of y'all who feel strongly about some of these defaults.
I encourage you to make a spin that caters to that experience.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Markus Larsson]

On 27 June 2020 21:34:17 CEST, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
> > Jesus Christ, this actually got approved. It's time to fork Fedora. This is 
> > really getting out of hand.
>
>
> As mentioned earlier, there's no need to "fork Fedora". It sounds like
> there
> are at least of few of y'all who feel strongly about some of these defaults.
> I encourage you to make a spin that caters to that experience.
>  
I was thinking more in the lines of a Remix.
Mainly to avoid spending time trying to get it blessed in the right forums.
If you think there room for a grumpy old neckbeard spin I'm sure I can find some time
to contribute.

/M

[John M. Harris Jr]

On Saturday, June 27, 2020 12:34:17 PM MST Matthew Miller wrote:
>  On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
>  
>  > Jesus Christ, this actually got approved. It's time to fork Fedora. This
>  > is  really getting out of hand.
>  
>  
>  
>  As mentioned earlier, there's no need to "fork Fedora". It sounds like
>  there are at least of few of y'all who feel strongly about some of these
>  defaults. I encourage you to make a spin that caters to that experience. 
Whoops, I forgot we can have spins with different defaults from the entire 
distro now. That wasn't the case last time I looked into that, and I was going 
to create a Remix.

-- 
John M. Harris, Jr.

[Peter Robinson]

>  On Saturday, June 27, 2020 12:34:17 PM MST Matthew Miller wrote:
>  > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
>  >
>  > > Jesus Christ, this actually got approved. It's time to fork Fedora. This
>  > > is  really getting out of hand.
>  >
>  >
>  >
>  > As mentioned earlier, there's no need to "fork Fedora". It sounds
> like
>  > there are at least of few of y'all who feel strongly about some of these
>  > defaults. I encourage you to make a spin that caters to that experience.
>
>  Whoops, I forgot we can have spins with different defaults from the entire
>  distro now. That wasn't the case last time I looked into that, and I was going
>  to create a Remix. 
Technically yes, see the fedora-release-* for one of the Editions, all
the spins should have the equivalent now, not sure if there's a FESCo
policy on it though.

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote:
>  On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
>  > Jesus Christ, this actually got approved. It's time to fork Fedora. This is 
>  > really getting out of hand.
>  
>  As mentioned earlier, there's no need to "fork Fedora". It sounds like
> there
>  are at least of few of y'all who feel strongly about some of these defaults.
>  I encourage you to make a spin that caters to that experience. 
I'm a fan of spins too, but making a spin to do
'touch /etc/systemd/zram-generator.conf' seems a bit much.

Zbyszek

[John M. Harris Jr]

On Sunday, June 28, 2020 12:18:32 PM MST Zbigniew Jędrzejewski-Szmek wrote:
>  On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote:
>  
>  > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
>  > 
>  > > Jesus Christ, this actually got approved. It's time to fork Fedora. This
>  > > is  really getting out of hand.
>  > 
>  > 
>  > As mentioned earlier, there's no need to "fork Fedora". It sounds
> like
>  > there are at least of few of y'all who feel strongly about some of these
>  > defaults. I encourage you to make a spin that caters to that experience.
>  
>  
>  I'm a fan of spins too, but making a spin to do
>  'touch /etc/systemd/zram-generator.conf' seems a bit much. 
Far from just that:

- Mask/disable systemd-homed
- Mask/disable systemd-userdb
- Mask/disable systemd-sysusers
- Mask/disable systemd-repart
- Mask/disable systemd-resolved
- Mask/disable systemd-networkd
- Mask/disable systemd-timesyncd
- Disable systemd-xdg-autostart-generator
- Remove the privacy anti-feature of using Google DNS when none are configured
- Disable fstrim.timer
- Disable EarlyOOM
- Not set a default EDITOR
- Not use btrfs or XFS as the default filesystem
- Have no modular repos by default

From this list, I know it might look like I'm calling out systemd. Well, 
that's just because it's become so bloated.

-- 
John M. Harris, Jr.

[Matthew Miller]

On Sun, Jun 28, 2020 at 07:28:34PM +0100, Peter Robinson wrote:
>  Technically yes, see the fedora-release-* for one of the Editions,
> all
>  the spins should have the equivalent now, not sure if there's a FESCo
>  policy on it though. 
The Council talked about this at our meeting in Minneapolis in 2018. We
didn't ask FESCo to update the technical policy to reflect the strategic
plan... but probably we should.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jun 28, 2020 at 01:32:41PM -0700, John M. Harris Jr wrote:
>  On Sunday, June 28, 2020 12:18:32 PM MST Zbigniew Jędrzejewski-Szmek
> wrote:
>  > On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote:
>  > 
>  > > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
>  > > 
>  > > > Jesus Christ, this actually got approved. It's time to fork Fedora.
> This
>  > > > is  really getting out of hand.
>  > > 
>  > > 
>  > > As mentioned earlier, there's no need to "fork Fedora". It sounds
> like
>  > > there are at least of few of y'all who feel strongly about some of these
>  > > defaults. I encourage you to make a spin that caters to that experience.
>  > 
>  > 
>  > I'm a fan of spins too, but making a spin to do
>  > 'touch /etc/systemd/zram-generator.conf' seems a bit much.
>  
>  Far from just that:
>  
>  - Mask/disable systemd-homed 
Doesn't do anything unless you create some users with homectl.

>  - Mask/disable systemd-userdb 
That's just a proxy service to provide user records as json. On its
own it doesn't really do much.

>  - Mask/disable systemd-sysusers 
Well, various packages make use of systemd-sysusers so if you disable
systemd-sysusers, they won't get a user created and will likely not
work. Also doesn't do anything if there's no configuration. But knock
yourself out.

>  - Mask/disable systemd-repart 
Doesn't do anything unless you provide a configuration file.

>  - Mask/disable systemd-resolved 
That's trivially disabled. The Change page lists a few mechanisms.

>  - Mask/disable systemd-networkd 
Doesn't do anything unless you provide configuration files.

>  - Mask/disable systemd-timesyncd 
Chrony is the default choice in Fedora, so until you uninstall chrony
and enable timesyncd, you're safe.

>  - Disable systemd-xdg-autostart-generator 
That's a mechanism for gnome and kde to spawn apps. Right now it's not
used yet, but it might in the future... I guess your best bet is not
to use gnome or kde. TWM would be a safe choice ;)

>  - Remove the privacy anti-feature of using Google DNS when none are
> configured 
In general people seem to prefer to have a functional network without
manual configuration. So we want to pick *some* default. Google DNS
seems to be not better or worse than other major providers. But if
you'd rather prefer to have no DNS if none is configured, it's still a
one line config to "fix" the issue.

>  - Disable fstrim.timer
>  - Disable EarlyOOM
>  - Not set a default EDITOR 
All those are trivially done with a single command or one-line file.

>  - Have no modular repos by default 
This one will soon be trivially done with a single command.

>  - Not use btrfs or XFS as the default filesystem 
Pick a different default when installing...

>  From this list, I know it might look like I'm calling out
> systemd. Well, 
>  that's just because it's become so bloated. 
I'd say "useful", but that's just words. Anyway, each of the items on
this list can be easily disabled. I guess you could provide a simple rpm
in a copr repo somewhere that does this.

Zbyszek

[John M. Harris Jr]

On Monday, June 29, 2020 12:58:30 AM MST Zbigniew Jędrzejewski-Szmek wrote:
>  On Sun, Jun 28, 2020 at 01:32:41PM -0700, John M. Harris Jr wrote:
*snip*
>  > - Mask/disable systemd-homed
>  
>  
>  Doesn't do anything unless you create some users with homectl. 
There's no reason for it to be there, wasting resources.

>  > - Mask/disable systemd-userdb
>  
>  
>  That's just a proxy service to provide user records as json. On its
>  own it doesn't really do much. 
That's awful, and the above applies there as well.

>  > - Mask/disable systemd-sysusers
>  
>  
>  Well, various packages make use of systemd-sysusers so if you disable
>  systemd-sysusers, they won't get a user created and will likely not
>  work. Also doesn't do anything if there's no configuration. But knock
>  yourself out. 
I don't think that's the case, since that Change required that `useradd` (or 
was it `adduser`?) be used. It'd be worth a try to remove the systemd bloat.

>  > - Mask/disable systemd-repart
>  
>  
>  Doesn't do anything unless you provide a configuration file. 
So it has no reason to be there.

>  > - Mask/disable systemd-resolved
>  
>  
>  That's trivially disabled. The Change page lists a few mechanisms. 
It's one of the many things in this list. Each one may be "trivially 
disabled", but it all adds up.

>  > - Mask/disable systemd-networkd
>  
>  
>  Doesn't do anything unless you provide configuration files. 
And, so, it shouldn't be there, wasting resources.

>  > - Mask/disable systemd-timesyncd
>  
>  
>  Chrony is the default choice in Fedora, so until you uninstall chrony
>  and enable timesyncd, you're safe. 
Same as above, it's unnecessary bloat.

>  > - Disable systemd-xdg-autostart-generator
>  
>  
>  That's a mechanism for gnome and kde to spawn apps. Right now it's not
>  used yet, but it might in the future... I guess your best bet is not
>  to use gnome or kde. TWM would be a safe choice ;) 
systemd has no place doing the DE's job. That's why I have a DE, instead of 
systemdOS. :)

>  > - Remove the privacy anti-feature of using Google DNS when none
> are
>  > configured
>  
>  In general people seem to prefer to have a functional network without
>  manual configuration. So we want to pick *some* default. Google DNS
>  seems to be not better or worse than other major providers. But if
>  you'd rather prefer to have no DNS if none is configured, it's still a
>  one line config to "fix" the issue. 
Generally, if there are no configured servers, people expect that.. there are 
no DNS servers in use. That's how it should be. I don't expect the system to 
outright subvert my intentions to run off to Google, and I'm sure others don't 
either. See the systemd-resolved Change "proposal" thread for more information 
on that.

>  > - Disable fstrim.timer
>  > - Disable EarlyOOM
>  > - Not set a default EDITOR
>  
>  
>  All those are trivially done with a single command or one-line file. 
That'd be the purpose of the Spin, so that users don't have to keep track of 
all of the things that need to be fixed.

>  > - Have no modular repos by default
>  
>  
>  This one will soon be trivially done with a single command. 
Yes, and that'll make it all the more simple to add it as an excluded package 
in the Spin's kickstart! ;)

>  > - Not use btrfs or XFS as the default filesystem
>  
>  
>  Pick a different default when installing... 
Hey, that's my line! Seriously though, that wasn't really a fair thing for me 
to write. At the time, I was of the attitude of "I don't really care if it 
breaks users' systems", and to "let those folks make a mockery of Fedora
with 
that default".

Sure, folks who are in the know will pick their own partitioning scheme and 
filesystems of choice. However, that doesn't solve the UX of a new user.

>  > From this list, I know it might look like I'm calling out
> systemd. Well, 
>  > that's just because it's become so bloated.
>  
>  
>  I'd say "useful", but that's just words. Anyway, each of the items on
>  this list can be easily disabled. I guess you could provide a simple rpm
>  in a copr repo somewhere that does this. 
I don't see why it'd need to be copr, I actually like mattdm's suggestion 
above. Some of these may need a bit more consideration, such as sysusers, but 
it'd have a lot of value to Fedora users.

-- 
John M. Harris, Jr.

[Matthew Miller]

On Sun, Jun 28, 2020 at 10:47:14PM -0400, Matthew Miller wrote:
>  The Council talked about this at our meeting in Minneapolis in 2018.
> We
>  didn't ask FESCo to update the technical policy to reflect the strategic
>  plan... but probably we should. 
https://pagure.io/fesco/issue/2418

(Includes links to the Council policies too for reference.)

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Sat, Jun 27, 2020 at 10:09:08PM +0200, Markus Larsson wrote:
>  I was thinking more in the lines of a Remix.
>  Mainly to avoid spending time trying to get it blessed in the right
>  forums. 
Sure, you could do that too. The process is to submit it as a Change to
FESCo just like this one, and since as I noted Fedora being able to provide
a variety of solutions catering to different users and use-cases is
literally in our mission, I don't think it should be particularly
controversial. People can disagree with what you're choosing for your spin,
but they don't have to use it. Just like you don't have to use nano. :)


>  If you think there room for a grumpy old neckbeard spin I'm sure
> I can
>  find some time to contribute. 
I mean... you might want to workshop that name a little bit. :)


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Markus Larsson]

On 29 June 2020 18:06:10 CEST, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> On Sat, Jun 27, 2020 at 10:09:08PM +0200, Markus Larsson wrote:
> > I was thinking more in the lines of a Remix.
> > Mainly to avoid spending time trying to get it blessed in the right
> > forums.
>
> Sure, you could do that too. The process is to submit it as a Change to
> FESCo just like this one, and since as I noted Fedora being able to provide
> a variety of solutions catering to different users and use-cases is
> literally in our mission, I don't think it should be particularly
> controversial. People can disagree with what you're choosing for your spin,
> but they don't have to use it. Just like you don't have to use nano. :) 
A spin feels like a commitment that involves gathering what other people feel and need.
While I'm cautious about some changes I tend to welcome change in general. I just need
to see the benefits and there needs to be reason to expect it to be successful.
I have a feeling that a neckbeard purist spin would be to conservative for me and I
don't want to invest work to get a spin approved and then land in a userbase of 1.
With a remix though I'm totally fine with putting work in for that single person
underbase :)

> > If you think there room for a grumpy old neckbeard spin I'm sure I can
> > find some time to contribute.
>
> I mean... you might want to workshop that name a little bit. :) 
Was it too honest?

>
>

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Matthew Miller]

On Mon, Jun 29, 2020 at 06:30:11PM +0200, Markus Larsson wrote:
>  A spin feels like a commitment that involves gathering what other
> people
>  feel and need. While I'm cautious about some changes I tend to welcome
>  change in general. I just need to see the benefits and there needs to be
>  reason to expect it to be successful. 
That's true, and I'll admit there's a little bit of "show me the
money" in
my stance here. The argument for these changes is based on the desire to
provide a better experience for an intended audience. But a number of people
in these threads are putting forth the assertation that there is a
meaningful number of users (including Fedora contributors) who would
actually be better served by a different set of defaults.

If there enough people who believe that and want to work on it, it should be
easy to find a core group of maintainers, go through the Change process to
propose it, and find an enthusiastic user-base. And I don't mean this in a
snarky way: it seems reasonable enough to me that there's a sustainable
level of interest. If there is, great! If there isn't, well, we also learn
something.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Markus Larsson]

On 29 June 2020 18:44:46 CEST, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> On Mon, Jun 29, 2020 at 06:30:11PM +0200, Markus Larsson wrote:
> > A spin feels like a commitment that involves gathering what other people
> > feel and need. While I'm cautious about some changes I tend to welcome
> > change in general. I just need to see the benefits and there needs to be
> > reason to expect it to be successful.
>
> That's true, and I'll admit there's a little bit of "show me the
> money" in
> my stance here. The argument for these changes is based on the desire to
> provide a better experience for an intended audience. But a number of people
> in these threads are putting forth the assertation that there is a
> meaningful number of users (including Fedora contributors) who would
> actually be better served by a different set of defaults. 
Well, there are. But the main gripe, for me, is that year for year the defaults keep
changing always catering to someone that is not me. Generally not because I'm changing
but because things are deemed not welcoming enough.
The Workstation installer is a prime example. I'm not saying it's bad just that I
feel that a working tool was taken from me and was replaced by something that satisfies my
needs to a much lesser extent.
I too see the need for being welcoming, I just wish it could be less heavy handed.
I also see a bit of arrogance towards new users, that they will break down crying if there
things that can be configured (yes hyperbolic but hyperbole is here used to show the
pattern, I'm not saying that people are actually arguing that users fall into tears if
displayed options).
I think most of these things could be solved in better ways, I don't think the
"change request"-route is a good way to get the discussion started though. It
tends to become mudslinging matches where those who proposed the changes feel obligated to
defend them and others become outraged.

> If there enough people who believe that and want to work on it, it should be
> easy to find a core group of maintainers, go through the Change process to
> propose it, and find an enthusiastic user-base. And I don't mean this in a
> snarky way: it seems reasonable enough to me that there's a sustainable
> level of interest. If there is, great! If there isn't, well, we also learn
> something. 
This and the btrfs stuff combined with earlier changes at least got me going on finally
setting up an auto deployment solution for my home environment. I just wish I didn't
have to.

>

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Matthew Miller]

On Mon, Jun 29, 2020 at 07:18:00PM +0200, Markus Larsson wrote:
>  I think most of these things could be solved in better ways, I
> don't think
>  the "change request"-route is a good way to get the discussion started
>  though. It tends to become mudslinging matches where those who proposed
>  the changes feel obligated to defend them and others become outraged. 
Yeah, I don't like that pattern either: that's actually why I'm suggesting
this. Rather than say no to other people, say yes to your own thing.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Markus Larsson]

On 29 June 2020 19:30:53 CEST, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> On Mon, Jun 29, 2020 at 07:18:00PM +0200, Markus Larsson wrote:
> > I think most of these things could be solved in better ways, I don't think
> > the "change request"-route is a good way to get the discussion started
> > though. It tends to become mudslinging matches where those who proposed
> > the changes feel obligated to defend them and others become outraged.
>
> Yeah, I don't like that pattern either: that's actually why I'm suggesting
> this. Rather than say no to other people, say yes to your own thing. 
I think it would be beneficial to lift up the problems we're trying to solve and then
work towards possible solutions.
I don't think it even would take more time. I would probably help people commit to the
problem and possibly accept the solution.
It seems to me that many feel out of the loop and thus reacts stronger than needed.

>

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Matthew Miller]

On Mon, Jun 29, 2020 at 07:46:53PM +0200, Markus Larsson wrote:
>  I think it would be beneficial to lift up the problems we're
> trying to
>  solve and then work towards possible solutions. I don't think it even
>  would take more time. I would probably help people commit to the problem
>  and possibly accept the solution. It seems to me that many feel out of the
>  loop and thus reacts stronger than needed. 
This is certainly one of the goals for the Editions strategy. Do

* https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
* https://fedoraproject.org/wiki/CoreOS/PRD#Target_Market_.2F_Audience
* https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Produ...

help?


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Markus Larsson]

On 29 June 2020 21:50:50 CEST, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> On Mon, Jun 29, 2020 at 07:46:53PM +0200, Markus Larsson wrote:
> > I think it would be beneficial to lift up the problems we're trying to
> > solve and then work towards possible solutions. I don't think it even
> > would take more time. I would probably help people commit to the problem
> > and possibly accept the solution. It seems to me that many feel out of the
> > loop and thus reacts stronger than needed.
>
> This is certainly one of the goals for the Editions strategy. Do
>
> * https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
> * https://fedoraproject.org/wiki/CoreOS/PRD#Target_Market_.2F_Audience
> * https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Produ...
>
> help?
>
>  
No that doesn't help at all. It doesn't address what I wrote about many seeing a
problem for the first time when a change is suggested and that this leads to more heated
debates than needed.
I also feel alienated by the target audience of Workstation since it pretty much only
talks about developers and others.
I guess "you aren't part of the target audience" is a nicer than saying
"take a hike neckbeard, this edition isn't even for you".
I'm pretty sure that wasn't the intended message though but I can't figure out
what the actual intended message was.
Please help :)

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Rahul Sundaram]

Hi

On Mon, Jun 29, 2020 at 4:30 PM Markus Larsson <qrsbrwn(a)uidzero.se&gt; wrote:

>  No that doesn't help at all. It doesn't address what I wrote about many
>  seeing a problem for the first time when a change is suggested and that
>  this leads to more heated debates than needed.
>  I also feel alienated by the target audience of Workstation since it
>  pretty much only talks about developers and others. 

It may very well be the case that workstation isn't what you are looking
for.  If you want to create your own remix or spin, one quick way to field
this is to create a package in copr or have an ansible playbook that sets
the defaults and configuration you want and gathering some feedback on
whether others find it useful.

Rahul

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Markus Larsson]

On 29 June 2020 22:33:43 CEST, Rahul Sundaram <metherid(a)gmail.com&gt; wrote:
> Hi
>
> On Mon, Jun 29, 2020 at 4:30 PM Markus Larsson <qrsbrwn(a)uidzero.se&gt; wrote:
>
> >
> > No that doesn't help at all. It doesn't address what I wrote about many
> > seeing a problem for the first time when a change is suggested and that
> > this leads to more heated debates than needed.
> > I also feel alienated by the target audience of Workstation since it
> > pretty much only talks about developers and others.
>
>
> It may very well be the case that workstation isn't what you are looking
> for.  If you want to create your own remix or spin, one quick way to field
> this is to create a package in copr or have an ansible playbook that sets
> the defaults and configuration you want and gathering some feedback on
> whether others find it useful.
>
> Rahul 
Thanks, I am well aware. That wasn't really the topic here.

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Rahul Sundaram]

Hi

On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote:

>  Thanks, I am well aware. That wasn't really the topic here.
>  
If there is a repeated feeling that anyone has that a particular edition
isn't what they are looking for, figuring out how to make a different set
of choices is and perhaps forming a community around their preferences is
pertinent.  This isn't addressed just to you.   Having said that, what do
you consider is the topic?

Rahul

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[John M. Harris Jr]

On Monday, June 29, 2020 5:04:18 PM MST Rahul Sundaram wrote:
>  Hi
>  
>  On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote:
>  > Thanks, I am well aware. That wasn't really the topic here.
>  
>  If there is a repeated feeling that anyone has that a particular edition
>  isn't what they are looking for, figuring out how to make a different set
>  of choices is and perhaps forming a community around their preferences is
>  pertinent.  This isn't addressed just to you.   Having said that, what do
>  you consider is the topic?
>  
>  Rahul 
The possibility of the start of the Grumpy Old Neckbeard Spin (actual name 
TBD).

-- 
John M. Harris, Jr.

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Markus Larsson]

On 30 June 2020 02:04:18 CEST, Rahul Sundaram <metherid(a)gmail.com&gt; wrote:
> Hi
>
> On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote:
>
> >
> > Thanks, I am well aware. That wasn't really the topic here.
> >
>
> If there is a repeated feeling that anyone has that a particular edition
> isn't what they are looking for, figuring out how to make a different set
> of choices is and perhaps forming a community around their preferences is
> pertinent.  This isn't addressed just to you.   Having said that, what do
> you consider is the topic?
>
> Rahul 
The topic at the moment was about how changes are made. It's also about highlighting
that when a distribution goes all in on the hunt for new users one has to figure out if
one wants to keep the old users.
I have been using fedora since FC1 and there has been a few shifts. The latest shift seems
to be a strong desire to be just another Ubuntu. That's fine, nothing wrong with
that... Do we need more Ubuntus though?

Regarding the language in the workstation target audience, well... I think it's narrow
and that it shouldn't be.

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Tomasz Torcz]

On Mon, Jun 29, 2020 at 06:29:09PM -0700, John M. Harris Jr wrote:
>  On Monday, June 29, 2020 5:04:18 PM MST Rahul Sundaram wrote:
>  > Hi
>  > 
>  > On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote:
>  > > Thanks, I am well aware. That wasn't really the topic here.
>  > 
>  > If there is a repeated feeling that anyone has that a particular edition
>  > isn't what they are looking for, figuring out how to make a different set
>  > of choices is and perhaps forming a community around their preferences is
>  > pertinent.  This isn't addressed just to you.   Having said that, what do
>  > you consider is the topic?
>  
>  The possibility of the start of the Grumpy Old Neckbeard Spin (actual name 
>  TBD). 
  Name it Fedora Devuan.

Nb. amount of negative stop-energy you demonstrate is huge. Could you
please try to be more productive and on-topic?

-- 
Tomasz Torcz                                                       72->|   80->|
tomek(a)pipebreaker.pl                                               72->|   80->|

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Matthew Miller]

On Tue, Jun 30, 2020 at 08:43:34AM +0200, Markus Larsson wrote:
>  I have been using fedora since FC1 and there has been a few shifts.
> The
>  latest shift seems to be a strong desire to be just another Ubuntu. That's
>  fine, nothing wrong with that... Do we need more Ubuntus though? 
I don't know what it means to "be another Ubuntu". We're a different
project
with a different structure and a different lineage.

Would I like the stuff we produce to be as popular as Ubuntu in terms of
user base? No -- I would like it to be more popular. And I think it's very
possible.

I know change is hard. I used to be a grumpy sysadmin myself and I can
relate to a lot of what you're saying. But I don't think the "alienating
current users vs. attracting new users" dichotomy is a useful one. Many
current users will also benefit from and appreciate the proposed changes.

However, one size definitely does not fit all, and our strategy is designed
*precisely* to address that.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Markus Larsson]

On 30 June 2020 16:52:52 CEST, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> On Tue, Jun 30, 2020 at 08:43:34AM +0200, Markus Larsson wrote:
> > I have been using fedora since FC1 and there has been a few shifts. The
> > latest shift seems to be a strong desire to be just another Ubuntu. That's
> > fine, nothing wrong with that... Do we need more Ubuntus though?
>
> I don't know what it means to "be another Ubuntu". We're a different
> project
> with a different structure and a different lineage. 
A distribution which has an aim to streamline the experience in order to cater to new
users.
Ubuntu is super good at this.

> Would I like the stuff we produce to be as popular as Ubuntu in terms of
> user base? No -- I would like it to be more popular. And I think it's very
> possible. 
I would like that too.

> I know change is hard. I used to be a grumpy sysadmin myself and I can
> relate to a lot of what you're saying. But I don't think the "alienating
> current users vs. attracting new users" dichotomy is a useful one. Many
> current users will also benefit from and appreciate the proposed changes. 
Please don't go "change is hard" on me. That is what management do when they
push for unpopular ideas.
My problem isn't with change, my problem is with how the change is done and in some
cases why the change is done.
Change is not only inevitable it's also the only way things can get better. That
doesn't mean that all changes are for the better.
As for the "old users vs new users" not being useful, well, there's a few
reasons why I'm still here. It's mainly that Fedora has good QA, SELinux and very
current software. That suits me well for my home environment. What is pretty clear
however, is that one can say "hold on how does this affect new users?" but
"how does this affect current users?" isn't as interesting.
I don't think the FOSS world needs another Ubuntu, Ubuntu already does that.
I think Fedora can compete with that without giving up inclusiveness. There can be a
Workstation edition that has sane defaults without hiding the fact that things can be
configured. 

> However, one size definitely does not fit all, and our strategy is designed
> *precisely* to address that. 
Well ofc, but if there is going to be a new spin for every taste then the fragmentation
will be a horrible. I'm a proponent of having a set of defaults and then having
flexibility since that means people can coexist. But that also means that there needs to
be flexibility in the install stage too.
I used to be able just grab an ISO of getfedora in case of emergency and get a replacement
machine up an running very quickly without much hassle because I could fix most things
during the install stage. Now I have instead built kickstarts for the relevant machines
and manage them via ansible. It's good sure but having to do it for my home
environment is mildly annoying.
So well, if I could find another distribution that is current, has good MAC and good QA I
would probably use that. Problem is that it doesn't really exist and I like Fedora.
I guess I'll just cover my own bases and mark workstation edition as Someone Elses
Problem.


>
>

[Sergio Belkin]

El vie., 5 jun. 2020 a las 16:10, John M. Harris Jr (<johnmh(a)splentity.com>)
escribió:

>  On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote:
>  > On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>  > >
>  > >
>  > > On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote:
>  >
>  >
>  >
>  > > > Also -1 to adding something to the core system that is written in a
>  > > > language for which we do not even have dynamic linking support. Or
>  > > > even real static linking support, as opposed to packaging libraries
>  as
>  > > > source code.> >
>  > > >         Kevin Kofler
>  > >
>  > >
>  > >
>  > > Agreed. Besides, GNOME already has this enabled, right? It's definitely
>  > > not right for servers, as I brought up the last time this was thrown
>  > > around.
>  >
>  > 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.
>
>  It really seems like this is wrong for most of Fedora, but that individual
>  parts, such as Fedora GNOME or IoT, should be left to make the decision
>  for
>  themselves, without affecting the rest.
>
>  --
>  John M. Harris, Jr.
>
>  _______________________________________________
>  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/[e-mail]
>  

At
https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-genera...
it says:

"Do not create swap partition/LV with default installations."
I don't understand if it is a description or a prescription :)I mean, can
coexist swap partition/LV and zram?

Thanks in advance!


-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org

[Samuel Sieb]

On 7/6/20 1:48 PM, Sergio Belkin wrote:
>  At 
>  https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-genera... 
>  it says:
>  
>  "Do not create swap partition/LV with default installations."
>  I don't understand if it is a description or a prescription :)I mean, 
>  can coexist swap partition/LV and zram? 
Yes, zram is just a compressed block device in RAM and it's being used 
here as swap.  You can have multiple swap devices active at the same 
time.  That's what I'm currently using.  I have a zram swap device and a 
disk swap partition as overflow.  But the plan is to avoid having any 
swap on disk by default.

[stan]

On Thu, 4 Jun 2020 16:30:07 -0400
Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/SwapOnZRAM 
>  ==== How can it be disabled? ====
>  
>  Immediately:</br >
>  <span style=color:red>swapoff /dev/zram0</span>
>  
>  Permanently:</br >
>  <span style=color:red>rm /etc/systemd/zram-generator.conf</span> 
I realize this is a really late reply, but I wanted to disable this
since it was never used, and when I looked at the man pages this
information was not in them.  I think it should be.

[Chris Murphy]

On Tue, Jul 28, 2020 at 11:29 AM stan via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On Thu, 4 Jun 2020 16:30:07 -0400
>  Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>
>  > https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>
>  > ==== How can it be disabled? ====
>  >
>  > Immediately:</br >
>  > <span style=color:red>swapoff /dev/zram0</span>
>  >
>  > Permanently:</br >
>  > <span style=color:red>rm /etc/systemd/zram-generator.conf</span>
>
>  I realize this is a really late reply, but I wanted to disable this
>  since it was never used, and when I looked at the man pages this
>  information was not in them.  I think it should be. 
That information is stale. The feature page has been updated.

man page contains:

       To  disable a configuration file supplied by the vendor, the
recommended way is to place a symlink to /dev/null in the
configuration directory in /etc/, with the same filename as the vendor
configuration file.


It's maybe easier to just 'dnf remove zram-generator-defaults' but
that is a Fedora specific instruction.


-- 
Chris Murphy

[John M. Harris Jr]

On Tuesday, July 28, 2020 12:51:00 PM MST Chris Murphy wrote:
>  On Tue, Jul 28, 2020 at 11:29 AM stan via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  
>  >
>  >
>  > On Thu, 4 Jun 2020 16:30:07 -0400
>  > Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>  >
>  >
>  >
>  > > ==== How can it be disabled? ====
>  > >
>  > >
>  > >
>  > > Immediately:</br >
>  > > <span style=color:red>swapoff /dev/zram0</span>
>  > >
>  > >
>  > >
>  > > Permanently:</br >
>  > > <span style=color:red>rm /etc/systemd/zram-generator.conf</span>
>  >
>  >
>  >
>  > I realize this is a really late reply, but I wanted to disable this
>  > since it was never used, and when I looked at the man pages this
>  > information was not in them.  I think it should be.
>  
>  
>  That information is stale. The feature page has been updated.
>  
>  man page contains:
>  
>         To  disable a configuration file supplied by the vendor, the
>  recommended way is to place a symlink to /dev/null in the
>  configuration directory in /etc/, with the same filename as the vendor
>  configuration file.
>  
>  
>  It's maybe easier to just 'dnf remove zram-generator-defaults' but
>  that is a Fedora specific instruction. 
Well, that'll just make it come back on upgrade, wouldn't it?


-- 
John M. Harris, Jr.

[Sergio Belkin]

El lun., 6 jul. 2020 a las 18:15, Samuel Sieb (<samuel(a)sieb.net>) escribió:

>  On 7/6/20 1:48 PM, Sergio Belkin wrote:
>  > At
>  >
>  https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-genera...
>  > it says:
>  >
>  > "Do not create swap partition/LV with default installations."
>  > I don't understand if it is a description or a prescription :)I mean,
>  > can coexist swap partition/LV and zram?
>
>  Yes, zram is just a compressed block device in RAM and it's being used
>  here as swap.  You can have multiple swap devices active at the same
>  time.  That's what I'm currently using.  I have a zram swap device and a
>  disk swap partition as overflow.  But the plan is to avoid having any
>  swap on disk by default.
>  _______________________________________________
>  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/[e-mail]
>  
Thanks, event for the late answer :)
 For the record, I'm using zram as a swap device and I disabled the swap on
disk. I have 16 GB of RAM and am using earlyoom on F32. There was only one
several issue using a lot of apps and VirtualBox VM's.
HTH

-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org

[Chris Murphy]

On Wed, Jul 29, 2020 at 12:56 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Tuesday, July 28, 2020 12:51:00 PM MST Chris Murphy wrote:
>  > On Tue, Jul 28, 2020 at 11:29 AM stan via devel
>  > <devel(a)lists.fedoraproject.org&gt; wrote:
>  >
>  > >
>  > >
>  > > On Thu, 4 Jun 2020 16:30:07 -0400
>  > > Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > >
>  > >
>  > >
>  > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>  > >
>  > >
>  > >
>  > > > ==== How can it be disabled? ====
>  > > >
>  > > >
>  > > >
>  > > > Immediately:</br >
>  > > > <span style=color:red>swapoff /dev/zram0</span>
>  > > >
>  > > >
>  > > >
>  > > > Permanently:</br >
>  > > > <span style=color:red>rm
> /etc/systemd/zram-generator.conf</span>
>  > >
>  > >
>  > >
>  > > I realize this is a really late reply, but I wanted to disable this
>  > > since it was never used, and when I looked at the man pages this
>  > > information was not in them.  I think it should be.
>  >
>  >
>  > That information is stale. The feature page has been updated.
>  >
>  > man page contains:
>  >
>  >        To  disable a configuration file supplied by the vendor, the
>  > recommended way is to place a symlink to /dev/null in the
>  > configuration directory in /etc/, with the same filename as the vendor
>  > configuration file.
>  >
>  >
>  > It's maybe easier to just 'dnf remove zram-generator-defaults' but
>  > that is a Fedora specific instruction.
>
>  Well, that'll just make it come back on upgrade, wouldn't it? 
No. I've updated the Upgrade and Compatibility section to reflect how
upgrades will work. It's quite a bit more narrow in scope than the
original proposal.

https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Upgrade.2Fcompatibility...

-- 
Chris Murphy

[stan]

On Tue, 28 Jul 2020 13:51:00 -0600
Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  That information is stale. The feature page has been updated.
>  
>  man page contains:
>  
>         To  disable a configuration file supplied by the vendor, the
>  recommended way is to place a symlink to /dev/null in the
>  configuration directory in /etc/, with the same filename as the vendor
>  configuration file. 
Thanks.

>  It's maybe easier to just 'dnf remove
> zram-generator-defaults' but
>  that is a Fedora specific instruction. 
After some thought, this is what I did after I posted the message.
Makes sense, can't run if it isn't there.