[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <qvqw350b2buj.fsf@devbig1114.prn1.facebook.com>
Date: Tue, 22 Aug 2023 11:03:16 -0700
From: Stefan Roesch <shr@...kernel.io>
To: David Hildenbrand <david@...hat.com>
Cc: kernel-team@...com, akpm@...ux-foundation.org,
linux-fsdevel@...r.kernel.org, hannes@...xchg.org,
riel@...riel.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v3] proc/ksm: add ksm stats to /proc/pid/smaps
David Hildenbrand <david@...hat.com> writes:
> On 17.08.23 18:23, Stefan Roesch wrote:
>> With madvise and prctl KSM can be enabled for different VMA's. Once it
>> is enabled we can query how effective KSM is overall. However we cannot
>> easily query if an individual VMA benefits from KSM.
>> This commit adds a KSM section to the /prod/<pid>/smaps file. It reports
>> how many of the pages are KSM pages. The returned value for KSM is
>> independent of the use of the shared zeropage.
>> Here is a typical output:
>> 7f420a000000-7f421a000000 rw-p 00000000 00:00 0
>> Size: 262144 kB
>> KernelPageSize: 4 kB
>> MMUPageSize: 4 kB
>> Rss: 51212 kB
>> Pss: 8276 kB
>> Shared_Clean: 172 kB
>> Shared_Dirty: 42996 kB
>> Private_Clean: 196 kB
>> Private_Dirty: 7848 kB
>> Referenced: 15388 kB
>> Anonymous: 51212 kB
>> KSM: 41376 kB
>> LazyFree: 0 kB
>> AnonHugePages: 0 kB
>> ShmemPmdMapped: 0 kB
>> FilePmdMapped: 0 kB
>> Shared_Hugetlb: 0 kB
>> Private_Hugetlb: 0 kB
>> Swap: 202016 kB
>> SwapPss: 3882 kB
>> Locked: 0 kB
>> THPeligible: 0
>> ProtectionKey: 0
>> ksm_state: 0
>> ksm_skip_base: 0
>> ksm_skip_count: 0
>> VmFlags: rd wr mr mw me nr mg anon
>> This information also helps with the following workflow:
>> - First enable KSM for all the VMA's of a process with prctl.
>> - Then analyze with the above smaps report which VMA's benefit the most
>> - Change the application (if possible) to add the corresponding madvise
>> calls for the VMA's that benefit the most
>> Signed-off-by: Stefan Roesch <shr@...kernel.io>
>> ---
>> Documentation/filesystems/proc.rst | 4 ++++
>> fs/proc/task_mmu.c | 5 +++++
>> 2 files changed, 9 insertions(+)
>> diff --git a/Documentation/filesystems/proc.rst
>> b/Documentation/filesystems/proc.rst
>> index 7897a7dafcbc..d5bdfd59f5b0 100644
>> --- a/Documentation/filesystems/proc.rst
>> +++ b/Documentation/filesystems/proc.rst
>> @@ -461,6 +461,7 @@ Memory Area, or VMA) there is a series of lines such as the following::
>> Private_Dirty: 0 kB
>> Referenced: 892 kB
>> Anonymous: 0 kB
>> + KSM: 0 kB
>> LazyFree: 0 kB
>> AnonHugePages: 0 kB
>> ShmemPmdMapped: 0 kB
>> @@ -501,6 +502,9 @@ accessed.
>> a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
>> and a page is modified, the file page is replaced by a private anonymous copy.
>> +"KSM" shows the amount of anonymous memory that has been de-duplicated. The
>> +value is independent of the use of shared zeropage.
>> +
>> "LazyFree" shows the amount of memory which is marked by madvise(MADV_FREE).
>> The memory isn't freed immediately with madvise(). It's freed in memory
>> pressure if the memory is clean. Please note that the printed value might
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 51315133cdc2..f591c750ffda 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -396,6 +396,7 @@ struct mem_size_stats {
>> unsigned long swap;
>> unsigned long shared_hugetlb;
>> unsigned long private_hugetlb;
>> + unsigned long ksm;
>> u64 pss;
>> u64 pss_anon;
>> u64 pss_file;
>> @@ -452,6 +453,9 @@ static void smaps_account(struct mem_size_stats *mss, struct page *page,
>> mss->lazyfree += size;
>> }
>> + if (PageKsm(page))
>> + mss->ksm += size;
>> +
>
> Did you accidentally not include handling of the KSM-shared zeropage?
>
> Or did I misinterpret "independent of the use of the shared zeropage."
I think I misunderstood your review comment. I'll address it in the next version.
Powered by blists - more mailing lists