Re: memory cgroup pagecache and inode problem

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

 




> On Jan 7, 2019, at 17:01, Fam Zheng <zhengfeiran@xxxxxxxxxxxxx> wrote:
> 
> 
> 
>> On Jan 7, 2019, at 16:53, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
>> 
>> On Mon 07-01-19 13:10:17, Fam Zheng wrote:
>>> 
>>> 
>>>> On Jan 5, 2019, at 03:36, Yang Shi <shy828301@xxxxxxxxx> wrote:
>>>> 
>>>> 
>>>> drop_caches would drop all page caches globally. You may not want to
>>>> drop the page caches used by other memcgs.
>>> 
>>> We’ve tried your async force_empty patch (with a modification to default it to true to make it transparently enabled for the sake of testing), and for the past few days the stale mem cgroups still accumulate, up to 40k.
>>> 
>>> We’ve double checked that the force_empty routines are invoked when a mem cgroup is offlined. But this doesn’t look very effective so far. Because, once we do `echo 1 > /proc/sys/vm/drop_caches`, all the groups immediately go away.
>>> 
>>> This is a bit unexpected.
>>> 
>>> Yang, could you hint what are missing in the force_empty operation, compared to a blanket drop cache?
>> 
>> I would suspect that not all slab pages holding dentries and inodes got
>> reclaimed during the slab shrinking inoked by the direct reclaimed
>> triggered by force emptying.
> 
> I don’t think so, we’ve ensured cgroup.memory=nokmem,nosocket first, as observed with the result of ‘echo 1’ command. It’s not slabs but the page caches holding mem cgroups.
> 
> It might well be that we’ve missing 68600f623d6, though. We’ll check it.

Just a follow-up: We’ve applied 68600f623d6 to 4.14, but it didn’t make a difference.

Fam

> 
> Thanks,
> 
> Fam
> 
>> -- 
>> Michal Hocko
>> SUSE Labs





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux