Re: Is there an official Fedora for WSL?

[Tomasz Torcz]

On Sat, Jun 06, 2020 at 07:15:57PM -0700, Gordon Messmer wrote:
> It's not click and run by any means, but it's feasible.
> 
> The bad news, though, is that current versions of rpm (and dnf) won't work
> under WSL if you're on a Windows version older than 2004, so you might be
> stuck with CentOS 7 if you're on an employer-managed laptop that is still
> running an older release of Windows (as I am, during the work day):
> https://github.com/Microsoft/WSL/issues/3939

  This bug manifests with BerkeleyDB. As we just moved off it,
and we are using SQLite for RPM database, current versions of
rpm and dnf should be fine.

-- 
Tomasz Torcz “God, root, what's the difference?”
to...@pipebreaker.pl   “God is more forgiving.”
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-31-20200607.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20200607.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/1 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 612945  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/612945
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Increasing the packaging team: regular workshops/vFADs/classroom sessions on packaging

[Ankur Sinha]

On Sat, Jun 06, 2020 06:40:43 -0500, Richard Shaw wrote:
> On Sat, Jun 6, 2020 at 5:54 AM Andy Mender  wrote:
> 
> Hiya,
> 
> As someone who is trying to get into packaging in Fedora, I would really
> really appreciate the docs being less dispersed:
> - https://docs.fedoraproject.org/en-US/packaging-guidelines/
> - https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package
> - https://rpm-packaging-guide.github.io/

There's a bit of complexity here that makes it hard to put everything in
one place:

- rpm is a package management system, and it is not specific to Fedora.
  So the rpm docs, as expected, live outside of Fedora

- The packaging guidelines are not "how to build rpms" in my book. They
  are the list of software development best practices that we follow
  while building rpms for inclusion in Fedora. So, our guidelines do not
  apply to other distributions using RPM. So, these live in the Fedora
  space.

I see
https://docs.fedoraproject.org/en-US/quick-docs/create-hello-world-rpm/
here, so perhaps the how to on the wiki can be merged there and a
redirect set up? Would anyone like to work on this? <- docs contribution
opportunity!

> Yes, the move to docs.fp.o is frustrating because googling what I need often
> points me to the old location and then I have to click the link to get to the
> new location. And while the docs site looks "prettier", everything seems to be
> "bigger" so it takes more scrolling to find what I need.

Quite a few of these are known issues, but the docs team needs more
manpower to solve them all. (In fact, the docs team seems to be barely
scraping by at the moment) Related tickets and discussion:

- adding search functions to docs.fp.o:
  https://pagure.io/fedora-docs/docs-fp-o/issue/2
- removal of old docs:
  https://pagure.io/fedora-docs/docs-fp-o/issue/128,
  https://pagure.io/fedora-docs/docs-fp-o/issue/67,
  https://pagure.io/fedora-docs/docs-fp-o/issue/30
  https://pagure.io/fedora-docs/docs-fp-o/issue/53
  
https://lists.fedoraproject.org/archives/list/d...@lists.fedoraproject.org/message/CZ7EQ6L7A6AUYDS4J6UMSSI2KL2T6QBC/

So, as with the rest of Fedora, the primary issue here is lack of
manpower.  I personally don't have a solution to this, but we're trying
to get more newbies involved using the Fedora Join SIG:
https://pagure.io/fedora-join/Welcome-to-Fedora

So if you run into newcomers, please send them to us. If you are
community member, please spare some time to help newcomers.

From AskFedora too, we try to get "users" to contribute to quick-docs as
a gateway to general contribution to Fedora:
https://ask.fedoraproject.org/t/optimus-setting-the-nvidia-gpu-as-primary-rpmfusion-in-fedora-32-workstation/6550
-> https://pagure.io/fedora-docs/quick-docs/pull-request/240 ->
https://docs.fedoraproject.org/en-US/quick-docs/how-to-set-nvidia-as-primary-gpu-on-optimus-based-laptops/

So, if you do have time, please also keep an eye on AskFedora and
suggest easy contribution tasks to "users".

Since attracting newcomer to increase our contribution base has always
been something we as a community tend to struggle with, this needs a
general CommOps/Mindshare/Council level plan perhaps. I don't know. I
don't make any proposals to them because I am unable to dedicate the
time to work on them myself.

(PS: I use "users" because I'm one of those people that do not believe
in the "user" "developer" dichotomy in FOSS. It tends to give people
outside the community a wrong sense of how we work---they treat us like
corporations that provide software and service in return for ... what?
So, I prefer to use "community members" for everyone: devs/users/non-dev
folks)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is there an official Fedora for WSL?

[Iñaki Ucar]

On Sun, 7 Jun 2020 at 04:22, Gordon Messmer  wrote:
>
> On 6/2/20 4:52 AM, Code Zombie wrote:
> > Is there an official branch of Fedora for WSL or a plan to create one?
>
>
> The good news is that it's reasonably straightforward to install an
> unpackaged distribution, you just need a tarball of the distribution.
> And lots of those are available for use with podman (or docker).  For
> example I can pull the CentOS 7 container image and then save that to an
> archive:
>
>  podman pull centos:7
>  podman save centos:7 -o centos7.tar
>
> Inside "centos7.tar" is another tar archive, which is the base layer for
> the centos:7 image.  Copy centos7.tar to your Windows system, and
> extract it there.  Now you can import that and then run it:
>
>  wsl --import centos7 c:\Users\\AppData\Local\Packages\Centos7
> centos7\*.tar
>  wsl -d centos7
>
> You'll usually want to set a registry key to change the default user...
> (HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{
> assigned GUID })
>
> It's not click and run by any means, but it's feasible.
>
> The bad news, though, is that current versions of rpm (and dnf) won't
> work under WSL if you're on a Windows version older than 2004, so you
> might be stuck with CentOS 7 if you're on an employer-managed laptop
> that is still running an older release of Windows (as I am, during the
> work day): https://github.com/Microsoft/WSL/issues/3939

I tried with Fedora rawhide (which already uses SQLite for the rpm
database) and it works fine, but:

- Instead of saving the image, a container must be exported:

$ podman run --name Fedora fedora:rawhide
$ podman export Fedora -o fedora.tar

- /etc/resolv.conf must be deleted, so that WSL creates its own one
and there's Internet access.
- You may want to delete tsflags=nodocs from /etc/dnf/dnf.conf
- I found that [1] does a pretty good job replacing /usr/bin/systemctl

[1] https://github.com/gdraheim/docker-systemctl-replacement

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Jeff Law]

On Sat, 2020-06-06 at 07:58 +0200, Igor Raits wrote:
> The big problem then becomes getting packagers to address the
> > diagnostics.  I've
> > been disappointed at how many packages are ignoring diagnostics
> > (particularly
> > those with security implications) and I'm actively looking at schemes
> > to improve
> > this situation :-)
> 
> Just make them error by default and people will have to deal with it :)
Easier said than done.  Though having something like the annobin/annocheck stuff
in place does help -- folks can't simply disable the warning in their package
which I've seen happen far too often.

One of the big problems is you can end up with a ton of local patches if the
upstream project doesn't take this stuff seriously.  And every one of those 
local
patches has a cost.  Naturally folks object to the initial work and ongoing 
cost,
particularly if upstream isn't on board.

So, if we do go forward with some of the ideas, they'll probably be some kind of
opt-in with packages where Red Hat's tools team has significant influence taking
the lead since the projects we work with regularly do generally take this stuff
seriously.   I have some thoughts on how to expand the set of packages covered,
but I'm not particularly ready to publicize those yet :-)

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

It seems that gdb cannot find debuginfo on f32

[Barry Scott]

I'm trying to debug a segv in PyQt5 and I hit a problem with gdb
not finding debug info in f32.

I have installed python3.8 debug info.

$ dnf list installed | grep debug | grep python3
python3-debuginfo.x86_64 3.8.3-1.fc32   

@updates-debuginfo
python3-debugsource.x86_64   3.8.3-1.fc32   

@updates-debuginfo
python3-qt5-base-debuginfo.x86_645.13.2-5.fc32  

@fedora-debuginfo

But still gdb says it cannot find the debuginfos.

$ gdb /usr/bin/python3.8
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python3.8...
Reading symbols from .gnu_debugdata for /usr/bin/python3.8...
(No debugging symbols found in .gnu_debugdata for /usr/bin/python3.8)
Missing separate debuginfos, use: dnf debuginfo-install 
python3-3.8.3-1.fc32.x86_64
(gdb) 

Am I doing something wrong?

Should I raise a BZ?

Barry


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Some services are failing to start with mount namespace errors

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jun 07, 2020 at 08:04:38AM +0200, Igor Raits wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On fully updated rawhide,
> 
> ● systemd-hostnamed.service - Hostname Service
>  Loaded: loaded (/usr/lib/systemd/system/systemd-hostnamed.service;
> static; vendor preset: disabled)
> Drop-In: /usr/lib/systemd/system/systemd-hostnamed.service.d
>  └─disable-privatedevices.conf
>  Active: failed (Result: exit-code) since Sun 2020-06-07 07:56:50
> CEST; 2min 19s ago
>Docs: man:systemd-hostnamed.service(8)
>  man:hostname(5)
>  man:machine-info(5)
> 
> https://www.freedesktop.org/wiki/Software/systemd/hostnamed
> Process: 4654 ExecStart=/usr/lib/systemd/systemd-hostnamed
> (code=exited, status=226/NAMESPACE)
>Main PID: 4654 (code=exited, status=226/NAMESPACE)
> CPU: 7ms
> 
> Jun 07 07:56:50 igors-t480s systemd[1]: Starting Hostname Service...
> Jun 07 07:56:50 igors-t480s systemd[4654]: systemd-hostnamed.service:
> Failed to set up mount namespacing: /run/systemd/unit-root/: Permission
> denied
> Jun 07 07:56:50 igors-t480s systemd[4654]: systemd-hostnamed.service:
> Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-hostnamed:
> Permission denied
> Jun 07 07:56:50 igors-t480s systemd[1]: systemd-hostnamed.service: Main
> process exited, code=exited, status=226/NAMESPACE
> Jun 07 07:56:50 igors-t480s systemd[1]: systemd-hostnamed.service:
> Failed with result 'exit-code'.
> Jun 07 07:56:50 igors-t480s systemd[1]: Failed to start Hostname
> Service.
> 
> Also seen this with fprintd and systemd-timedated.
> 
> fprintd.service: Failed to set up mount namespacing: /run/systemd/unit-
> root/: Permission denied
> fprintd.service: Failed at step NAMESPACE spawning
> /usr/libexec/fprintd: Permission denied
Most of the time, such errors are caused by mislabelling and selinux
denials. Does it work in non-enforcing mode?

> Restarting those services make them work fine sometimes, but not
> always.
> 
> Any ideas where to report this bug?
Bugzilla.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: broken threads

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jun 05, 2020 at 02:43:49PM -0700, Samuel Sieb wrote:
> On 6/5/20 2:14 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > This has been bothering me for a while, it occurs quite often for
> > certain posters to the list, and since Jeff's replies reproduce this
> > issue, let me ask:
> > 
> > Why is the threading broken with Jeff's replies to this thread?
> > Looking at the headers, there is no In-reply-to: header.
> > Is this caused by the agent: User-Agent: Evolution 3.36.2 (3.36.2-1.fc32) ?
> 
> Yes, this was explained earlier.  He's getting the list in digest form and
> Evolution isn't able to break it up properly to set the correct subjects and
> in-reply-to headers.

Hi Jeff,

would it be possible for you to instead start replying to mails in the
main thread then? Currently, each of your mails starts a new "thread",
making it very very hard to follow the conversation for those of us
who rely on traditional threading behaviour. I'd be very grateful.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: swap-on-ZRAM by default

[Konstantin Kharlamov]

Hello! I see a proposal to enable zram by deafult¹. If I correctly
understand this is the thread where it's being discussed. I have a few
questions, answers to which probably would be nice to add to the
proposal.

1. It says ZRAM gets enabled on upgrade. What's gonna happen to systems
with ZSWAP is enabled? I guess it doesn't make sense to keep them both.
2. I was a bit shocked to see comparison to a system with 16GB of RAM.
I admit the more the better, but most people still have only 8GB on
their laptops/PCs, and sometimes there's just 4GB of RAM.
   My question is: given people with 4GB of RAM, are you sure that
handing 2GB over to ZRAM gonna improve their experience?

The third question touches the paragraph "Why not zswap?". The only
point it mentions is that swap-device is not encrypted. Fair enough,
although I wonder why this never has been regarded as a problem before.

I have an actual user experience which suggests ZSWAP might be a better
choice. My gf is using Macbook with Fedora, with 4GB of RAM and an SSD
device. She loves opening lots of tabs in a browser, and as you can
expect RAM gets quickly exhausted.

With 2GB of SSD SWAP she was getting lags sometimes ("sometimes", SWAP
on SSD is much faster than on HDD). 3-4 months ago I enabled 1GB of
ZSWAP, and lags are gone.

Would your proposal with ZRAM help here? Sadly no, there's more to the
story. The 2GB of SWAP turns out not to be enough, it gets regularly
exhausted. I even had to create a script that pops up a warning when
SWAP is low on space, so she'd close some tabs² (for some boring reason
it's a bit hard to increase SWAP space there).

Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is not
enough! The moral of this story is that you can't get away with only
ZRAM without any disk SWAP. You need disk SWAP. And if you have disk
SWAP, ZSWAP fits more nicely there as a compressing buffer before the
data finally spills over to disk.

1: https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_not_zswap.3F
2: 
https://github.com/Hi-Angel/scripts/blob/master/warn-on-low-memory.pl
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[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@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[stan via devel]

On Thu, 4 Jun 2020 16:30:09 -0400
Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/CompilerPolicy

> An obvious example is Firefox.  Upstream, the Firefox project builds
> primarily with Clang/LLVM.  Yet we force the Fedora package owner to
> find and fix issues building with GCC then either carry those custom
> fixes forward in Fedora or negotiate with upstream to get those
> changes upstreamed.  While this process can be helpful in finding
> non-portable code, this is ultimately a poor use of the packager's
> time.

I compile firefox nightly locally from an hg repository.  What I notice
is that although mozilla officially states that it is possible to limit
resource use, even though I set a maximum thread count, or maximum
load, the clang compiler grabs every core and maxes it out to 100%.
Will this change help with that?  i.e.  is this a clang problem?  Or is
my experience because of a problem with the firefox compilation process?
Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

CPE Weekly: 2020-06-07

[Aoife Moloney]

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-06-07

Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers
can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

Please check out our updated initiative timetable for briefing in new
projects to our team
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.

Dont forget to view our taiga board to see the projects we are
currently working on, what we have scoped and whats in our backlog
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null


CPE Product Owner Office Hours: Thursdays @ 1300 UTC on #fedora-meeting-1









## Fedora Updates




### Data Centre Move
* A reduced services offering of Fedora will begin tomorrow, June 8th
until July 28th, est.
* This is to complete the final shipment of hardware from Phoenix to
Washington, so please be patient and understanding during this
timeframe as some services will be off and the rest, much slower.
* Please read the below email sent by kfenzi if you have not already
done so: 
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/E7HJULW2S76FZCAICURWXX223N5ZXXD7/
* Details on what this move may mean for you can be found here
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/27U6YT73556KYW2RIFJO6J2HYMYVP22U/
* If an application is not working correctly at all, please check this
list https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view before opening a
ticket to make sure its not listed as being moved. If it is being
moved, please wait a day or two, then try again.
* Similarly, please be patient when opening tickets for service issues
in general as we have now reached the critical point in this move and
all of our sys-admins and wider teams will be assisting in the
successful bringup of the reduced Fedora service and facilitation of
the final hardware shipment and move.



### AAA Replacement
* The team are working on implementing an aspect of the service that
will allow users to select their applicable contributor agreement(s)
as we are merging both Fedora and CentOS authentication system under
the Noggin' solution.
* The team have also added a blog pref to the feature set in Noggin
* They have added pagination to the solution
* And are working through redirecting applications to interface with the new API
* Please feel free to check out the team kanban board for more
information on the features the team are working on and have already
completed here https://github.com/orgs/fedora-infra/projects/6





### Mbbox
* Project Dashboard here https://github.com/fedora-infra/mbbox/projects/1
* Sprint 4 is underway with the following work being addressed:
* Kojira CRD & Documentation completed
* MBS Backend CRD is almost done
* And the team are now waiting on a staging environment to deploy
and test in. We hope to have this in place by the end of this week



### Gitforge
Good discussion on the CPE PO Office Hours meeting this Thursday, 4th
June around the possibility of scheduling an AMA session/technical
panel session with some folks from GitLab to allow the Fedora
community a direct line to discuss services, potential blockers, etc.
General feedback is that this will be welcome so I will work with
GitLab and cverna, who is still leading the technical side of the
project (link to ticket below) to plan the best time for this session
& work with you all to set an agenda/discussion points for the
meeting. NOTE: Due to the data centre move, this session will not
happen before late August or early September at a minimum. Thank you
for your engagement with us on this!
Link to public issue ticket:
https://gitlab.com/gitlab-org/gitlab/-/issues/217350
Meeting minutes log
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-06-04/cpe_po_office_hours.2020-06-04-13.00.log.html



## CentOS Updates

### CentOS
*  CentOS Linux 8.2.2004 RC composes are with QA




### CentOS Stream
* The team resolved all of the 8.2 build failures in CentOS Stream in
their recent sprint (May 21st - June 5th)
* An issue where a SIG was unable to push new content to
git.centos.org was resolved, and is currently in staging
* The team are also investigating how best to separate CentOS Linux
branding from CentOS Stream
* We are also focusing on building more packages in Stream for our
current sprint (June 5th - 19th) and working on more automation and
variance to help improve the current process and time it takes for our
team

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

[Chris Murphy]

On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga  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@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@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Chris Murphy]

On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann  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

Re: swap-on-ZRAM by default

[Chris Murphy]

On Sun, Jun 7, 2020 at 12:56 PM Konstantin Kharlamov  wrote:
>
> Hello! I see a proposal to enable zram by deafult¹. If I correctly
> understand this is the thread where it's being discussed. I have a few
> questions, answers to which probably would be nice to add to the
> proposal.
>
> 1. It says ZRAM gets enabled on upgrade. What's gonna happen to systems
> with ZSWAP is enabled? I guess it doesn't make sense to keep them both.

Good question! I will add this to the feedback section.

- there is no immediate conflict between them, system will boot
normally and there will be no errors in the journal
- since you've already decided to dedicate X% to zswap's cache, which
is a preallocation, the feature does intervene in your preferred setup
by favoring the swaponzram first, before the workload hits zswap. And
only if it fills up the zram device first.

My recommendation?

rm /etc/systemd/zram-generator.conf

That will disable this feature.




> 2. I was a bit shocked to see comparison to a system with 16GB of RAM.
> I admit the more the better, but most people still have only 8GB on
> their laptops/PCs, and sometimes there's just 4GB of RAM.
>My question is: given people with 4GB of RAM, are you sure that
> handing 2GB over to ZRAM gonna improve their experience?

Yes. Not that while zswap's cache preallocates memory. Whereas the
zram module does not preallocate memory to /dev/zram0. It's used only
on demand.

So in the 4G RAM case, a 2G zram device will use 256M-1G of memory
depending on the compression ratio (which I'm seeing 4:1 to 2:1).

>
> The third question touches the paragraph "Why not zswap?". The only
> point it mentions is that swap-device is not encrypted. Fair enough,
> although I wonder why this never has been regarded as a problem before.

It's definitely regarded as a problem. Perhaps not quite on par with
user home not being encrypted but swap is known to be a potential
source of leaking user data. To a lesser extent, /var and /etc. And
also the initramfs is a weak point too, in that it's not signed.

https://pagure.io/fedora-workstation/issue/82
https://pagure.io/fedora-workstation/issue/136

> Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is not
> enough! The moral of this story is that you can't get away with only
> ZRAM without any disk SWAP. You need disk SWAP. And if you have disk
> SWAP, ZSWAP fits more nicely there as a compressing buffer before the
> data finally spills over to disk.

Your use case is intentionally overcommitting available memory and it
sounds like you don't have much choice in that you (a) the workload
you have is the workload you need to run, and (b) memory isn't
upgradeable.

You should consider testing whether swap-on-zram sized to 100% RAM
fits your use case better. And in fact if your workload gets very good
compression ratios, it can be quite reasonable to go higher than 100%.

An alternative explanation is that you've found the sweet spot with
the zswap setup you have already.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: swap-on-ZRAM by default

[Chris Murphy]

By the way, shout out to Bastien Nocera. This feature was his idea
before I got around to picking it up and running with it.

https://pagure.io/fedora-workstation/issue/98


---
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[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


signature.asc
Description: PGP si

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

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Chris Murphy]

On Sun, Jun 7, 2020 at 7:31 PM David Kaufmann  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200607.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200606.n.0
NEW: Fedora-Rawhide-20200607.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  1
Dropped packages:0
Upgraded packages:   59
Downgraded packages: 0

Size of added packages:  1.54 MiB
Size of dropped packages:0 B
Size of upgraded packages:   4.13 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   67.81 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20200606.n.0.iso

= ADDED PACKAGES =
Package: glues-1.5-1.20200105git44cb7c6.fc33
Summary: GLU port for OpenGL ES
RPMs:glues glues-devel
Size:1.54 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Agda-2.6.0.1-22.fc33
Old package:  Agda-2.6.0.1-21.fc32
Summary:  A dependently typed functional programming language and proof 
assistant
RPMs: Agda ghc-Agda ghc-Agda-devel ghc-Agda-doc ghc-Agda-prof 
ghc-EdisonAPI ghc-EdisonAPI-devel ghc-EdisonAPI-doc ghc-EdisonAPI-prof 
ghc-EdisonCore ghc-EdisonCore-devel ghc-EdisonCore-doc ghc-EdisonCore-prof 
ghc-geniplate-mirror ghc-geniplate-mirror-devel ghc-geniplate-mirror-doc 
ghc-geniplate-mirror-prof ghc-murmur-hash ghc-murmur-hash-devel 
ghc-murmur-hash-doc ghc-murmur-hash-prof ghc-uri-encode ghc-uri-encode-devel 
ghc-uri-encode-doc ghc-uri-encode-prof
Dropped RPMs: Agda-common
Size: 275.13 MiB
Size change:  1.80 MiB
Changelog:
  * Wed May 27 2020 Jens Petersen  - 2.6.0.1-22
  - move statically linked /usr/bin/agda and datadir into base package
  - also drop common subpackage


Package:  Agda-stdlib-1.2-1.fc33
Old package:  Agda-stdlib-1.1-2.fc32
Summary:  Agda standard libraries
RPMs: Agda-stdlib Agda-stdlib-docs
Size: 253.06 MiB
Size change:  58.60 MiB
Changelog:
  * Tue May 26 2020 Jens Petersen  - 1.2-1
  - update to 1.2
  - https://github.com/agda/agda-stdlib/blob/v1.2/CHANGELOG.md
  - requires Agda instead of ghc-Agda now


Package:  Lmod-8.3.15-1.fc33
Old package:  Lmod-8.3.14-1.fc33
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.05 MiB
Size change:  403 B
Changelog:
  * Sat Jun 06 2020 Orion Poplawski  - 8.3.15-1
  - Update to 8.3.15


Package:  PDAL-2.1.0-8.fc33
Old package:  PDAL-2.1.0-7.fc33
Summary:  Point Data Abstraction Library
RPMs: PDAL PDAL-devel PDAL-doc PDAL-libs
Size: 63.51 MiB
Size change:  8.16 KiB
Changelog:
  * Wed Jun 03 2020 Markus Neteler  2.1.0-8
  - enable EPEL8 compilation by dropping sphinx docs for now


Package:  R-simmer-4.4.2-1.fc33
Old package:  R-simmer-4.4.1-1.fc33
Summary:  Discrete-Event Simulation for R
RPMs: R-simmer R-simmer-devel
Size: 8.65 MiB
Size change:  38.59 KiB
Changelog:
  * Sat Jun 06 2020 I??aki ??car  - 4.4.2-1
  - Update to 4.4.2


Package:  airinv-1.00.4-3.fc33
Old package:  airinv-1.00.4-2.fc33
Summary:  C++ Simulated Airline Inventory Management System library
RPMs: airinv airinv-devel airinv-doc
Size: 3.95 MiB
Size change:  447.51 KiB
Changelog:
  * Sat Jun 06 2020 Denis Arnaud  - 1.00.4-3
  - Rebuilt for SOCI 4.0.1-alpha2


Package:  airrac-1.00.4-3.fc33
Old package:  airrac-1.00.4-2.fc33
Summary:  C++ Simulated Revenue Accounting (RAC) System Library
RPMs: airrac airrac-devel airrac-doc
Size: 1.41 MiB
Size change:  171.34 KiB
Changelog:
  * Sat Jun 06 2020 Denis Arnaud  - 1.00.4-3
  - Rebuilt for SOCI 4.0.1.alpha2


Package:  airtsp-1.01.7-3.fc33
Old package:  airtsp-1.01.7-2.fc33
Summary:  C++ Simulated Airline Travel Solution Provider Library
RPMs: airtsp airtsp-devel airtsp-doc
Size: 2.74 MiB
Size change:  278.88 KiB
Changelog:
  * Sat Jun 06 2020 Denis Arnaud  - 1.01.7-3
  - Rebuilt for SOCI 4.0.1-alpha2


Package:  awscli-1.18.74-1.fc33
Old package:  awscli-1.18.73-1.fc33
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.75 MiB
Size change:  215 B
Changelog:
  * Sat Jun 06 2020 Gwyn Ciesla  - 1.18.74-1
  - 1.18.74


Package:  cinnamon-4.6.3-1.fc33
Old package:  cinnamon-4.6.2-1.fc33
Summary:  Window management and application launching for GNOME
RPMs: cinnamon cinnamon-devel-doc
Size: 8.25 MiB
Size change:  323 B
Changelog:
  * Sat Jun 06 2020 Leigh Scott  - 4.6.3-1
  - Update to 4.6.3 release


Package:  cinnamon-desktop-4.6.1-1.fc33
Old package:  cinnamon-desktop-4.6.0-1.fc33
Summary:  Shared code among cinnamon-session, nemo, etc
RPMs: cinnamon-desktop cinnamon-desktop-devel
Size: 1.82 MiB
Size change:  1.30 KiB
Changelog:
  * Sat Jun 06 2020 Leigh Scott  - 4.6.1-1
  - Update to 4.6.1 release


Package:  ddnet-13.2.2-1.fc33
Old package:  ddnet-13.2.1-1.fc33
Summary:  DDraceNetwork, a cooperative racing mod of Teeworlds
RPMs: ddnet ddnet-data ddnet-server
Size

Re: Is there an official Fedora for WSL?

[Gordon Messmer]

On 6/7/20 12:47 AM, Tomasz Torcz wrote:

On Sat, Jun 06, 2020 at 07:15:57PM -0700, Gordon Messmer wrote:

The bad news, though, is that current versions of rpm (and dnf) won't work
under WSL if you're on a Windows version older than 2004, so you might be
stuck with CentOS 7 if you're on an employer-managed laptop that is still
running an older release of Windows (as I am, during the work day):
https://github.com/Microsoft/WSL/issues/3939

   This bug manifests with BerkeleyDB. As we just moved off it,
and we are using SQLite for RPM database, current versions of
rpm and dnf should be fine.



You're right.  "Current" was probably the wrong word.  RHEL/CentOS 8 
don't work, and I don't expect the newest release of Fedora does, 
either.  Rawhide should, as Iñaki mentioned.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is there an official Fedora for WSL?

[Gordon Messmer]

On 6/7/20 5:22 AM, Iñaki Ucar wrote:

I tried with Fedora rawhide (which already uses SQLite for the rpm
database) and it works fine, but:

- Instead of saving the image, a container must be exported:



Right, you can export a container, or you can save an image and use the 
layer tarball inside the resulting tarball.  The saved image isn't a 
usable tarball itself, but it does contain a usable tarball.




- /etc/resolv.conf must be deleted, so that WSL creates its own one
and there's Internet access.



I didn't need to do that when using the "saved" image, for what that's 
worth.




- You may want to delete tsflags=nodocs from /etc/dnf/dnf.conf



Good call.



- I found that [1] does a pretty good job replacing /usr/bin/systemctl
[1] https://github.com/gdraheim/docker-systemctl-replacement



I only use WSL for an interactive shell, so I haven't needed to do much 
of anything with systemd.  Does it not run in WSL, out of curiosity?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: swap-on-ZRAM by default

[John M. Harris Jr]

On Sunday, June 7, 2020 11:51:38 AM MST Konstantin Kharlamov wrote:
> Hello! I see a proposal to enable zram by deafult¹. If I correctly
> understand this is the thread where it's being discussed. I have a few
> questions, answers to which probably would be nice to add to the
> proposal.
> 
> 1. It says ZRAM gets enabled on upgrade. What's gonna happen to systems
> with ZSWAP is enabled? I guess it doesn't make sense to keep them both.
> 2. I was a bit shocked to see comparison to a system with 16GB of RAM.
> I admit the more the better, but most people still have only 8GB on
> their laptops/PCs, and sometimes there's just 4GB of RAM.
>My question is: given people with 4GB of RAM, are you sure that
> handing 2GB over to ZRAM gonna improve their experience?
> 
> The third question touches the paragraph "Why not zswap?". The only
> point it mentions is that swap-device is not encrypted. Fair enough,
> although I wonder why this never has been regarded as a problem before.

An important consideration is that zram is *also* not encrypted. If that's 
enough to rule out zswap, it should be enough to rule out zram too.

> I have an actual user experience which suggests ZSWAP might be a better
> choice. My gf is using Macbook with Fedora, with 4GB of RAM and an SSD
> device. She loves opening lots of tabs in a browser, and as you can
> expect RAM gets quickly exhausted.
> 
> With 2GB of SSD SWAP she was getting lags sometimes ("sometimes", SWAP
> on SSD is much faster than on HDD). 3-4 months ago I enabled 1GB of
> ZSWAP, and lags are gone.
> 
> Would your proposal with ZRAM help here? Sadly no, there's more to the
> story. The 2GB of SWAP turns out not to be enough, it gets regularly
> exhausted. I even had to create a script that pops up a warning when
> SWAP is low on space, so she'd close some tabs² (for some boring reason
> it's a bit hard to increase SWAP space there).
> 
> Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is not
> enough! The moral of this story is that you can't get away with only
> ZRAM without any disk SWAP. You need disk SWAP. And if you have disk
> SWAP, ZSWAP fits more nicely there as a compressing buffer before the
> data finally spills over to disk.
> 
> 1: https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_not_zswap.3F
> 2: 
> https://github.com/Hi-Angel/scripts/blob/master/warn-on-low-memory.pl

Zswap sounds like an excellent idea to look into instead of zram. Not only 
that, but it'd allow traditional entry in fstab to configure it, instead of 
some systemd magic that nobody knows about.

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Luya Tshimbalanga]

> On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga 
>  
> 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@zram0.service 
● zram-setup@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@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Chris Murphy]

On Sun, Jun 7, 2020 at 11:25 PM Luya Tshimbalanga
 wrote:
>
> > On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga 
> >  >
> > 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@zram0.service
> ● zram-setup@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: swap-on-ZRAM by default

[Chris Murphy]

On Mon, Jun 8, 2020 at 12:35 AM Chris Murphy  wrote:
>
> zswap is configured by sysfs, same as zram.
>

s/by/via/



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: swap-on-ZRAM by default

[Chris Murphy]

On Sun, Jun 7, 2020 at 11:18 PM John M. Harris Jr  wrote:
>
> On Sunday, June 7, 2020 11:51:38 AM MST Konstantin Kharlamov wrote:

> > The third question touches the paragraph "Why not zswap?". The only
> > point it mentions is that swap-device is not encrypted. Fair enough,
> > although I wonder why this never has been regarded as a problem before.
>
> An important consideration is that zram is *also* not encrypted. If that's
> enough to rule out zswap, it should be enough to rule out zram too.

/dev/zram0 isn't persistent.


> > Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is not
> > enough! The moral of this story is that you can't get away with only
> > ZRAM without any disk SWAP. You need disk SWAP. And if you have disk
> > SWAP, ZSWAP fits more nicely there as a compressing buffer before the
> > data finally spills over to disk.
> >
> > 1: https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_not_zswap.3F
> > 2:
> > https://github.com/Hi-Angel/scripts/blob/master/warn-on-low-memory.pl
>
> Zswap sounds like an excellent idea to look into instead of zram. Not only
> that, but it'd allow traditional entry in fstab to configure it, instead of
> some systemd magic that nobody knows about.

zswap is configured by sysfs, same as zram.

It's a consideration, but I'm uncertain if it can happen for F33.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1844664] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS [fedora-all]

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1844664

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
Version|32  |31
   Fixed In Version||perl-5.30.3-452.fc31




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: swap-on-ZRAM by default

[Konstantin Kharlamov]

On Sun, 2020-06-07 at 18:19 -0600, Chris Murphy wrote:
> On Sun, Jun 7, 2020 at 12:56 PM Konstantin Kharlamov <
> hi-an...@yandex.ru> wrote:
> > Hello! I see a proposal to enable zram by deafult¹. If I correctly
> > understand this is the thread where it's being discussed. I have a
> > few
> > questions, answers to which probably would be nice to add to the
> > proposal.
> >
> > 1. It says ZRAM gets enabled on upgrade. What's gonna happen to
> > systems
> > with ZSWAP is enabled? I guess it doesn't make sense to keep them
> > both.
>
> Good question! I will add this to the feedback section.
>
> - there is no immediate conflict between them, system will boot
> normally and there will be no errors in the journal
> - since you've already decided to dedicate X% to zswap's cache, which
> is a preallocation, the feature does intervene in your preferred
> setup
> by favoring the swaponzram first, before the workload hits zswap. And
> only if it fills up the zram device first.
>
> My recommendation?
>
> rm /etc/systemd/zram-generator.conf
>
> That will disable this feature.

Thanks! While it's great there's a manual solution, I'd expect there's
a big percent of users who would not know about upcoming enabling of
ZRAM. Should there be some automatic decision? For example, either
disabling ZSWAP or disabling ZRAM? Or perhaps popping up a warning on
upgrade where a user given a choice whether to disable one or another?

> > Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is not
> > enough! The moral of this story is that you can't get away with
> > only
> > ZRAM without any disk SWAP. You need disk SWAP. And if you have
> > disk
> > SWAP, ZSWAP fits more nicely there as a compressing buffer before
> > the
> > data finally spills over to disk.
>
> Your use case is intentionally overcommitting available memory and it
> sounds like you don't have much choice in that you (a) the workload
> you have is the workload you need to run, and (b) memory isn't
> upgradeable.
>
> You should consider testing whether swap-on-zram sized to 100% RAM
> fits your use case better. And in fact if your workload gets very
> good
> compression ratios, it can be quite reasonable to go higher than
> 100%.

Thanks! I'll give it a try, will report back.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org