subject:"\[Bug 1833281\]"

[Bug 1833281]

2022-03-27 Thread hi-angel

Modern kernels handle SWAPPING situations much better.

Also, these days the Multi-LRU patchset should pretty much resolve the
problem. It is not yet upstream, but is used in downstream kernels such
as linux-zen and liquorix-kernel. There is hope it will be merged by
5.19¹

1: https://www.phoronix.com/scan.php?page=news_item=MGLRU-Not-
For-5.18

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1833281/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1833281]

2022-01-20 Thread egorfedorovichletov

Are there any changes?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1833281/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1833281] Re: System freeze when memory is put on SWAP in Linux >4.10.x

2020-12-24 Thread Kevin Wortman

I am experiencing this bug on a stock Dell Inspiron 5000 (5482) with 8
GB RAM and the factory SSD. It is completely debilitating. Having 1-2
completely unpredictable, 30-minute-plus, hard freezes per day is a
showstopper. I can't trust this environment for professional work, or
even to take notes in gedit during a phone call.

I've been an Ubuntu user and advocate at work and home for 10+ years,
but I guess I have to quit :(

I tried different flavors, and the bug manifested under all of them:
Ubuntu LTS 20.04, Ubuntu 20.10, Ubuntu MATE 20.10, and Debian 10.

Fedora 33 does not suffer from this bug, so I'm using that. I get
frequent "Gah! Your tab just crashed" errors in Firefox any time I have
more than about 5 tabs open. I conjecture there is some difference
between the Redhat-based and Debian-based kernels, that causes the
Redhat-based ones to kill a tab process in the circumstance that causes
the Debian-based ones to lock up. The Fedora experience is acceptable,
though it's still disappointing that Linux performance is has regressed
to be inadequate for basic web browsing.

Takeaway: Fedora seems to be an acceptable workaround for people
experiencing this bug.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1833281/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1833281]

2020-09-23 Thread admin

@lou +1

Sorry for my Google translate.


This bug is very many years old. This is *Bug 12309* !!! Why didn't anyone 
remember?


I'm tired of him. Was in the early 2010s for 512 MB of RAM. Was in the early 
2010s for 512 MB of RAM. and 2 GB of RAM. Mid 2010s with 4GB of RAM. And for 
the past five years, 16 GB of RAM has not gone anywhere.


There is a funny article in Russian about this bug lurkmore.to/12309 with links 
to the original bug reports and "problem solutions" in each new kernel. 
"According to the anonymous author, this useful feature is LOVE AND CAREFULLY 
into a fresh kernel."


Earlier I tried to rebuild kernels according to the advice on the Internet 
(BFQ). Sometimes it helped a little. Some assemblies gave time to urgently 
close programs. But the most effective was vm.swappiness = 90 and a script with 
a notification when approaching this value to clean up memory (conky + dialog).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1833281/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1833281] Re: System freeze when memory is put on SWAP in Linux >4.10.x

2020-03-31 Thread Kai-Heng Feng

Possible duplicate of LP: #1861359.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1833281/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1833281]

2020-03-30 Thread russianneuromancer

On HP Stream 7 Tablet (1GB RAM) there was similar regression, but it
started since Linux 4.12 instead of 4.10. Last year I tried bisect and
several workarounds such as autostart cleanup, sysctl tweaks, zram, etc.
But in the end it's seems like Linux 5.5.8 solved issue, at least in
this particular use-case (device with 1GB RAM) 5.5.8 makes swapping
perform like it was with 4.11.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1833281/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1833281]

2020-03-30 Thread bugzilla

Another resource, quite long but has a tl;dr, and reviewed by some of the 
cgroups/resource control folks:
https://chrisdown.name/2018/01/02/in-defence-of-swap.html

I'll use somewhat technically sloppy language, but hopefully a useful
metaphor: there's incidental swap and heavy swap. Incidental swap is
when some file or anonymous page really isn't needed, and it's good to
evict it to free up memory. But in the case of heavy swap (or even
reclaim), not at all incidental, it becomes a serious performance
impediment. The reality is that there are some tasks that just take gobs
of memory and swap isn't a good substitute. But some swap is useful for
freeing up memory for things that need to stay in memory.

I'm finding for the incidental swap need, swap-on-ZRAM is quite useful.
You are exchanging an IO bound task for a memory+CPU task; also it
forces such pages to be pinned into memory. So there's no free lunch.
Conservative use would be a ZRAM device around 1/4 of RAM up to a max of
50% RAM. It's not bad or wrong to use more, it's just that some
workloads, like the webkitgtk example, have such significant need that
it'll actually turn 1/2 of memory into swap, which in effect means you
have 50% less RAM for that task. It actually makes the problem worse.
Really, the near term is a) build with flags that cause fewer resources
to be used in the firist place, or b) build in a systemd user session
and limit resources that way, or c) buy more RAM, or d) use conventional
swap partition, possibly with zswap to leave the most frequent pages in
a small RAM cache pool, that's big enough for the task to eventually
complete and just suffer with the ensuing lack of GUI responsiveness.

Anyway, it's a bit complicated. And lots of moving parts. And probably
needs more sophisticate use of perf and maybe even bpf could be useful
in figuring where the various bottlenecks are.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1833281/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

I primarily test by building webkitgtk [1], and I experience the same loss of
system responsiveness whether / is ext4 or Btrfs. But I do see a difference in
top and iotop.
https://drive.google.com/open?id=12jpQeskPsvHmfvDjWSPOwIWSz09JIUlk

This is an extreme case of refaulting, it's out of memory and swap, and
since kswapd and btrfs threads are using a lot of CPU I'm guessing the
faults are a mix of anonymous pages and file pages. At this point the
system is really lost which is why the UX is the same with ext4 and
btrfs; but behind the scenes it does seem more is going on. There might
be other workloads which aren't as extreme, thereby exposing the
difference. Two possible sources of the heavy CPU for btrfs threads:
decompression, and checksumming. If it's true there is near constant
reclaim happening, it's not just a simple minimum 4K read but rather a
128K minimum because all Btrfs compressed files use 128K extent size; is
then decompressed, and then requires reading csum tree and computing
csum on the read to compare. Ordinarily this is cheap but in this
situation possibly it's resulting in a lot of extra congestion, but this
is the limit of my knowledge so it's just speculation.

Btrfs write amplification is a known issue (wandering trees problem).
But that appears to not be the issue in this example.

It might be this problem is better dealt with by cgroupsv2 to protect certain
tasks from reclaim, and thus reduce the problem on any file system. But Btrfs
alone (for now) does have more sophisticated cgroupvs2 IO isolation control as
well.
https://www.spinics.net/lists/cgroups/msg24743.html

The upstream GNOME and KDE developers are aware of the loss of responsiveness
problem and have done quite a lot of preliminary work in GNOME 3.34 with more
work on the way.
https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/

You can today take advantage of this cgroupsv2 work by running resource hungry
tasks as a systemd user unit in Fedora 31.
https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/#comment-14833

I expect in the next 6-12 months (it's a guesstimate) there will be
additional work in GNOME to protect the user session or what I vaguely
call the "GUI stack" from reclaim, and thus improve its responsiveness
at the expense of the resource hungry process.

[1] first two lines; set -j to RAM in GiB +2 GiB; i.e. if you have 8G RAM, use
-j 10; more jobs makes the problem happen faster.
https://trac.webkit.org/wiki/BuildingGtk

62 matches

Mail list logo