Re: Increasing amount of cached (unflushed/un-invalidated) file pages causing kernel panics

[mlelstv%serpens.de@localhost (Michael van Elst)]

fgsdfg4t534tf3%onet.pl@localhost (Marcin Kaminski) writes:

>Whatever I do on aarch64 port, let it be building release, writing file rec=
>eived by NFSd, executing command like 'dd if=3D/dev/zero bs=3D1m count=3D20=
>00' or running firefox, number of file pages(reported by systat bufcache or=
> top(file mem)) increases monotonically up to the moment of kernel panic

It would be helpful to have some details about the kernel panic.
If that really is a panic you see a panic message or something like
'UVM fault'.  The system then tries to reboot with the default
setting.

You can set

  ddb.onpanic=1
  ddb.commandonenter="trace;show registers"

in /etc/sysctl.conf. Then, instead of a reboot, the system will
enter the kernel debugger and print a stack trace and dump CPU
registers.


>To reproduce problem:
>execute:
>	* dd if=3D/dev/zero bs=3D1m count=3D<about 85% of RAM> > testfile    - on =
>ffs filesystem(what =
>		* supsequently run memory consuming program: firefox, NFSd server receivi=
>ng(or sending) big(relatively to RAM amount) file, iso image for instance

The expected behaviour is that the system gets very busy until
enough memory is freed, then everything should work normally. This
can take some time and the system may look stalled or frozen.

There are also situations where the system may lock up. Either
because page daemon heuristics are invalid (memory isn't freed
although there is demand) or because free memory requires allocating
memory (either buffers or some kernel structures) and that fails.
Freeing memory by e.g. terminating a program or reducing the vnode
cache then resolves the lock. This obviously shouldn't happen.


>	* userland programs like: scsictl or dkctl returned problems with executio=
>n of cache related commands

Neither program is related to memory usage or the "file cache".
Both can issue cache operations on the particular disk hardware,
if that hardware supports it.


>Tested on:
>	* Rock64(not 'Pro' variant)  (4GB RAM)
>	* Odroid C2 (2GB RAM)

>Expected behavior:
>	* gradual, progressive flushing/invalidating of (expired?) cached file pag=
>es	=

The dirty pages are written out, but cached data is only removed
when there is demand for memory.


>In general: Is there any way to manually flush/invalidate cached file pages=
>(reported by 'systat bufcache' or top(as 'file' memory) for ffs or/and zfs =
>filesystem?

Not directly, however, reducing kern.maxvnodes (with sysctl) has
a similar effect. Don't reduce to very low values (>1000 is fine).
When the value is reduced, the system flushes vnodes and cached
data associated with these vnodes until the limit is reached.

Restore the limit to the old value, otherwise the system will be
slow.

N.B. nothing of this is related to aarch64.


Greetings,