Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Hello,

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


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


Further observations:
	* on amd64 port, despite of quite little free memory being eventually reported, system doesn't crashes. Perhaps somehow balancing on RAM shortage(reporting < 1m of free memory)
	* vfs.sync.*delay options seemed to me appropriate but decreasing their values doesn't help
	* functions I preasume are related(from different levels of abstraction): man VFS_SYNC / man cache_purgevfs / man vflush 
	* userland programs like: scsictl or dkctl returned problems with execution of cache related commands

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

Expected behavior:
	* gradual, progressive flushing/invalidating of (expired?) cached file pages	

Accepted behavior:
	* manual, on demand flushing/invalidating of all(or most) cached file pages, equivalent of Linux's:
		echo 2 > /proc/sys/vm/drop_caches


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?

I spend some time trying to debug problem, looking in(and building release with patches) vfs_mount.c, ffs_vfsops.c, ffs_vnops.c, uvm_pdaemon.c, vfs_subr.c, nonetheless lack of knowledge how to use sleep(like) function from kernelspace severely hinders my further debugging(i.e. searching for the kernel code fragments resposible for flushing/invalidating file pages - also(?) when removing cached file(rm testfile) or unmounting whole filesystem cached file(s) reside(s) in)


It is a problem that prevents me from using NetBSD to much wider extent. I really doubt I'm the only person affected by that issue.

Is that really problem of aarch64 or am I missing something ?

I readily test any patches regarding this issue.


Thanks for all your work poeple, it's simply awesome.
Best regards.




Home | Main Index | Thread Index | Old Index