lkml.org 
[lkml]   [2019]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm, slab: Extend slab/shrink to shrink all the memcg caches
From
Date
On 7/22/19 8:46 AM, peter enderborg wrote:
> On 7/2/19 8:37 PM, Waiman Long wrote:
>> Currently, a value of '1" is written to /sys/kernel/slab/<slab>/shrink
>> file to shrink the slab by flushing all the per-cpu slabs and free
>> slabs in partial lists. This applies only to the root caches, though.
>>
>> Extends this capability by shrinking all the child memcg caches and
>> the root cache when a value of '2' is written to the shrink sysfs file.
>>
>> On a 4-socket 112-core 224-thread x86-64 system after a parallel kernel
>> build, the the amount of memory occupied by slabs before shrinking
>> slabs were:
>>
>> # grep task_struct /proc/slabinfo
>> task_struct 7114 7296 7744 4 8 : tunables 0 0
>> 0 : slabdata 1824 1824 0
>> # grep "^S[lRU]" /proc/meminfo
>> Slab: 1310444 kB
>> SReclaimable: 377604 kB
>> SUnreclaim: 932840 kB
>>
>> After shrinking slabs:
>>
>> # grep "^S[lRU]" /proc/meminfo
>> Slab: 695652 kB
>> SReclaimable: 322796 kB
>> SUnreclaim: 372856 kB
>> # grep task_struct /proc/slabinfo
>> task_struct 2262 2572 7744 4 8 : tunables 0 0
>> 0 : slabdata 643 643 0
>
> What is the time between this measurement points? Should not the shrinked memory show up as reclaimable?

In this case, I echoed '2' to all the shrink sysfs files under
/sys/kernel/slab. The purpose of shrinking caches is to reclaim as much
unused memory slabs from all the caches, irrespective if they are
reclaimable or not. We do not reclaim any used objects. That is why we
see the numbers were reduced in both cases.

Cheers,
Longman

\
 
 \ /
  Last update: 2019-07-23 16:30    [W:0.059 / U:3.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site