| Message ID | 20230808170858.397542-1-shr@devkernel.io (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1] proc/ksm: add ksm stats to /proc/pid/smaps | expand |
Andrew Morton <akpm@linux-foundation.org> writes: > On Tue, 8 Aug 2023 10:08:58 -0700 Stefan Roesch <shr@devkernel.io> 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. >> >> 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 > > smaps is documented in Documentation/filesystems/proc.rst, please. > (And it looks a bit out of date). > I'll add the documentation of the knob. > Did you consider adding this info to smaps_rollup as well? I'll have a look.
Andrew Morton <akpm@linux-foundation.org> writes: > On Tue, 8 Aug 2023 10:08:58 -0700 Stefan Roesch <shr@devkernel.io> 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. >> >> 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 > > smaps is documented in Documentation/filesystems/proc.rst, please. > (And it looks a bit out of date). > > Did you consider adding this info to smaps_rollup as well? The smaps_rollup is covered. Under the covers it uses the same code as smaps.
On 08.08.23 19:17, Andrew Morton wrote: > On Tue, 8 Aug 2023 10:08:58 -0700 Stefan Roesch <shr@devkernel.io> 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. >> >> 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 > > smaps is documented in Documentation/filesystems/proc.rst, please. > (And it looks a bit out of date). > > Did you consider adding this info to smaps_rollup as well? It would be great to resend that patch to linux-mm + kernel. Otherwise I'll have to do some digging / downloading from linux-fsdevel ;)
David Hildenbrand <david@redhat.com> writes: > On 08.08.23 19:17, Andrew Morton wrote: >> On Tue, 8 Aug 2023 10:08:58 -0700 Stefan Roesch <shr@devkernel.io> 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. >>> >>> 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 >> smaps is documented in Documentation/filesystems/proc.rst, please. >> (And it looks a bit out of date). >> Did you consider adding this info to smaps_rollup as well? > > It would be great to resend that patch to linux-mm + kernel. Otherwise I'll have > to do some digging / downloading from linux-fsdevel ;) I'll cc linux-mm + kernel on the next version.
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; + mss->resident += size; /* Accumulate the size in pages that have been accessed. */ if (young || page_is_young(page) || PageReferenced(page)) @@ -822,6 +826,7 @@ static void __show_smap(struct seq_file *m, const struct mem_size_stats *mss, SEQ_PUT_DEC(" kB\nPrivate_Dirty: ", mss->private_dirty); SEQ_PUT_DEC(" kB\nReferenced: ", mss->referenced); SEQ_PUT_DEC(" kB\nAnonymous: ", mss->anonymous); + SEQ_PUT_DEC(" kB\nKSM: ", mss->ksm); SEQ_PUT_DEC(" kB\nLazyFree: ", mss->lazyfree); SEQ_PUT_DEC(" kB\nAnonHugePages: ", mss->anonymous_thp); SEQ_PUT_DEC(" kB\nShmemPmdMapped: ", mss->shmem_thp);
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. 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@devkernel.io> --- fs/proc/task_mmu.c | 5 +++++ 1 file changed, 5 insertions(+) base-commit: f4a280e5bb4a764a75d3215b61bc0f02b4c26417