| 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
| ||
|
Message-ID: <20170110103211.arb3sqv54hu4gdiy@m.mifar.in> Date: Tue, 10 Jan 2017 12:32:11 +0200 From: Sami Farin <hvtaifwkbgefbaei@...il.com> To: linux-kernel@...r.kernel.org Cc: linux-mm@...ck.org Subject: Re: [BUG] How to crash 4.9.2 x86_64: vmscan: shrink_slab On Tue, Jan 10, 2017 at 10:22:41 +0100, Michal Hocko wrote: > On Mon 09-01-17 23:02:10, Sami Farin wrote: > > # sysctl vm.vfs_cache_pressure=-100 > > > > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535449472 > > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535450112 ... > > > > > > Alternatively, > > # sysctl vm.vfs_cache_pressure=10000000 > > Both values are insane and admins do not do insane things to their > machines, do they? Not on purpose, unless they are insane :) Docs say: "Increasing vfs_cache_pressure significantly beyond 100 may have negative performance impact." Nothing about crashing. But anyways, the problem I originally had was: with vm.vfs_cache_pressure=0 , dentry/inode caches are reclaimed at a very alarming rate, and when I e.g. rescan quodlibet media directory (only 30000 files), that takes a lot of time.. I only download some files for a minute and dentry/inode caches are reclaimed, or so it seems. Still, SReclaimable keeps on increasing, when it gets to about 6 GB , I increase vm.vfs_cache_pressure .... -- Do what you love because life is too short for anything else. https://samifar.in/
Powered by blists - more mailing lists