Re: How to controll Buffers to be dilligently reclaimed?

[Cheng Rk <crquan@ymail.com>]

On Wednesday, February 18, 2015 6:23 AM, Michal Hocko <mhocko@suse.cz> wrote:
On Fri 13-02-15 09:52:16, Cheng Rk wrote:

> As per Documentation/sysctl/vm.txt the knob doesn't affect the page
> cache reclaim but rather inode vs. dentry reclaim.


So do you think is it worth to work on something to give pressure similar
to vm.vfs_cache_pressure to vfs inode & dentry cache?

I am looking for an effect to let the kernel more aggressively reclaim
memory from Buffers,


By reading fs/super.c:prune_super I've also realized taht, which is the
only place referening sysctl_vfs_cache_pressure,
that block_devices' inode are in "bdev" mount, its super_block just
have nr_cached_objects as NULL,
s_nr_dentry_unused and s_nr_inodes_unused both 0, get total_objects to be
reclaimed is 0;

So is why sysctl_vfs_cache_pressure doesn't give pressure to Buffers,


         if (sb->s_op && sb->s_op->nr_cached_objects)
                   fs_objects = sb->s_op->nr_cached_objects(sb);

  total_objects = sb->s_nr_dentry_unused +
                                         sb->s_nr_inodes_unused + fs_objects;

  total_objects = (total_objects / 100) * sysctl_vfs_cache_pressure;
  drop_super(sb);


In crash, I got to know this block_device (253:2, or /dev/dm-2)has 10536805 pages mapped, that is the 40GB memory in Buffers, I wonder is there a sysctl can controll this to be reclaimed earlier?


crash> block_device.bd_dev,bd_inode -x ffff880619c78000
bd_dev = 0xfd00002
bd_inode = 0xffff880619c780f0
crash> inode.i_mapping 0xffff880619c780f0
i_mapping = 0xffff880619c78240
crash> address_space.nrpages 0xffff880619c78240
nrpages = 10536805


>> I have some oom-killer msgs but were with older kernels, after set>> vm.overcommit_memory=2, it simply returns -ENOMEM, unable to spawn any
>> new container, why doesn't it even try to reclaim some memory from

>> those 40GB Buffers,> overcommit_memory controls behavior of the _virtual_ memory
> reservations. OVERCOMMIT_NEVER (2) means that even virtual memory cannot
> be overcommit outside of the configured value (RAM + swap basically -
> see Documentation/vm/overcommit-accounting for more information). So
> your application most probably consumes a lot of virtual memory (mmaps
> etc.) and that is why it gets ENOMEM.


I have read that Doc as well, will post again when I get a more concrete example

> OOM report would tell us what was the memory state at the time when you
> were short of memory and why the cache (buffers in your case) were not
> reclaimed properly.


Thanks,

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>