linux-kernel - Freezing between .48 and .51 when hitting swap.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAN-MDmparVyT2ZRp4x2=cBxm_k+iuyAJ4_xTELT07w+f0hu2bg@mail.gmail.com>
Date:   Sun, 1 Nov 2020 16:46:58 +0000
From:   NASA Jeff <tallboy258@...il.com>
To:     Linux Kml <linux-kernel@...r.kernel.org>
Subject: Freezing between .48 and .51 when hitting swap.

I have an issue on my laptop which is old but with 2.5gb of ram an ssd
hdd and using zram compression I believe.
When ever it hits swap the system completely locks up and I have to reboot.
This only started occurring in .51
I only have access to my phone at the moment though I’ve looked at the
code and have what I believe is a workable solution that should
mitigate against and future issues. The code base looked a little old
so was probably quite stable but it really could do with some
modernisation.
The issue was with the active app in user space.
What needs to be done is to swap out inactive pages in background user
apps prior to the active apps hitting the memory threshold which was
causing the lockup to occure.

An improvement on the existing code would be to swap in and out
inactive pages gradually so as to avoid any heavy system load.

It may also be an idea to set the up priority to near idel for such
heavy io background processes so that the overlapping io doesn’t cause
issues with user space io.

I believe this is similar to the main Linux scheduler since bfs
because implementing a script to renice processes that started hitting
higish cpu and then again when their cpu dipped didn’t seem to make
much difference. It was unclear if this was also implemented for
cocurent io as the window managers now seem to queue io tasks instead
of executing them concurrently. Concurrent io was at least a historic
issue.

Kind regards,
Oliverthered