Received-SPF: pass (google.com: domain of linux-kernel+bounces-203141-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240605123710.7396-1-00107082@163.com>
In-Reply-To: <20240605123710.7396-1-00107082@163.com>
From: Suren Baghdasaryan <surenb@google.com>
Date: Wed, 5 Jun 2024 13:00:17 -0700
Message-ID: <CAJuCfpFY=e3zNOMHgTM-HGxhk2c_nr=ODOo3Fk67_D4gNgzx-Q@mail.gmail.com>
Subject: Re: [BUG?] memory allocation profiling: the counters are not non-decreasing.
To: David Wang <00107082@163.com>
Cc: kent.overstreet@linux.dev, keescook@chromium.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 5, 2024 at 5:37=E2=80=AFAM David Wang <00107082@163.com> wrote:
>
> Hi,
> I was playing with this new feature of memory allocation profiling, when =
I plot the data, grouped by caller's source dir,
> I noticed that the counters are not non-decreasing.
> If I understand this feature correctly, all counters should be non-decrea=
sing, right?
> Or is there some TTL for stale items?

Hi David,
Counters can decrease once an allocation is freed.
Thanks,
Suren.

>
> Following is a simpler script demonstrating my sayings
>
>         $ for i in {1..100}; do sudo cat /proc/allocinfo | grep " mm\/" |=
 awk '{s+=3D$2}END{print s}'; sleep 10; done
>         1194453
>         1196935
>         1198957
>         1199716
>         1200770
>         1190795  <--- decrease here
>         1192702
>         1193070
>         1193812
>         1195069
>         1196491
>         ...
>
> FYI
> David
>