#1 general improvements
Closed 2 months ago by chrismurphy. Opened 2 months ago by chrismurphy.
rpms/ chrismurphy/zram devel  into  master

file modified
+1

@@ -2,6 +2,7 @@ 

  Description=Enable compressed swap in memory using zram

  DefaultDependencies=no

  Before=swap.target

+ Conflicts=umount.target

Why the conflicts here? You don't say in the commit message

  

  [Service]

  Type=oneshot

file modified
+1 -1

@@ -1,4 +1,4 @@ 

- # The factor is the percentage of total system RAM to allocate to the ZRAM block device(s).

+ # The factor determines the ratio 1/n of RAM to allocate to the ZRAM block device, where FACTOR = n.

  FACTOR=2

  

  PRIORITY=1000

file modified
+1 -1

@@ -12,7 +12,7 @@ 

  mem_total=$(free -w |grep "^Mem" |awk '{printf("%d",$2)}')

  zram_size=$((${mem_total} / ${factor} /1024))

  

- # zram in recent kernels is multitreaded so we don't need to balance across CPUs

+ # ZRAM in recent kernels is multithreaded so we don't need to balance across CPUs

  modprobe -q zram num_devices=1

  

  # Create ZRAM with first device, lz4 algorithm

file modified
+1 -6

@@ -1,10 +1,5 @@ 

  #!/bin/sh

  

  for i in $(grep '^/dev/zram' /proc/swaps | awk '{ print $1 }'); do

- 	swapoff "$i"

+ 	swapoff "$i" && zramctl --reset "$i"

  done

- 

- if grep -q "^zram " /proc/modules; then

- 	sleep 1

- 	rmmod zram

- fi

Three minor changes, one bigger change with zramstop to add hot remove of the device instead of unloading the kernel module. Tested locally.[14013.719587] zram: Added device: zram0
[14013.727782] zram0: detected capacity change from 0 to 3925000192
[14013.739158] Adding 3833004k swap on /dev/zram0. Priority:1000 extents:1 across:3833004k SSFS
[14044.424852] zram0: detected capacity change from 3925000192 to 0
[14044.424981] zram: Removed device: zram0
[root@fmac ~]# uname -r
5.2.0-0.rc5.git0.1.fc31.x86_64+debug

Why the conflicts here? You don't say in the commit message

Mostly looks fine, I just have the one query.

https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2

tear down zram swap before umount all

https://bugzilla.redhat.com/show_bug.cgi?id=1469726#c9

Zbigniew used it in that comment, and after reading about ordering in systemd, I figure that plausibly something could be swapped out that would cause umount to hang, and it's better to stop swap before attempting umount? I can just ask on the systemd list and then we're sure, yes?

Zbigniew used it in that comment, and after reading about ordering in systemd, I figure that plausibly something could be swapped out that would cause umount to hang, and it's better to stop swap before attempting umount? I can just ask on the systemd list and then we're sure, yes?

Yes please, just to make sure we're not cargo culting something. Thanks

They've discussed it with some back and forth; last two paragraphs in this contain the decision to not use it.
https://lists.freedesktop.org/archives/systemd-devel/2019-June/042968.html

So just reject commit 63900c.

They've discussed it with some back and forth; last two paragraphs in this contain the decision to not use it.
https://lists.freedesktop.org/archives/systemd-devel/2019-June/042968.html

Thanks for the update

So just reject commit 63900c.

I don't see how that can be done in the pagure UX, if you just update the patch series and push it to the same branch the PR should be updated, then I'll merge it

Pull-Request has been closed by chrismurphy

2 months ago