From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) by kanga.kvack.org (Postfix) with ESMTP id A88136B0003 for ; Wed, 18 Jul 2018 14:43:57 -0400 (EDT) Received: by mail-ua0-f199.google.com with SMTP id r6-v6so1873714uan.7 for ; Wed, 18 Jul 2018 11:43:57 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id o3-v6sor1850890uae.20.2018.07.18.11.43.56 for (Google Transport Security); Wed, 18 Jul 2018 11:43:56 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180717212307.d6803a3b0bbfeb32479c1e26@linux-foundation.org> <20180718104230.GC1431@dhcp22.suse.cz> From: Bruce Merry Date: Wed, 18 Jul 2018 20:43:55 +0200 Message-ID: Subject: Re: Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Shakeel Butt Cc: Michal Hocko , Andrew Morton , LKML , Linux MM , Johannes Weiner , Vladimir Davydov On 18 July 2018 at 20:13, Shakeel Butt wrote: > On Wed, Jul 18, 2018 at 10:58 AM Bruce Merry wrote: > Yes, if there is no memory pressure such memory can stay around. > > On your production machine, before deleting memory containers, you can > try force_empty to reclaim such memory from them. See if that helps. Thanks. At the moment the cgroups are all managed by systemd and docker, but I'll keep that in mind while experimenting. Bruce -- Bruce Merry Senior Science Processing Developer SKA South Africa