+ On 17/01/2025 01:19, Tejun Heo wrote: > Hello, > > On Thu, Jan 16, 2025 at 05:50:54AM +0000, Zhijian Li (Fujitsu) wrote: > ... >> Let me quote a piece of the numa.stat: >> >> In pages: >>> pgdemote_khugepaged >>> Number of pages demoted by khugepaged. > > If this is the only entry in pages, I'm not sure the proposed document > update is the best one. I asked the ChatGPT with the contents in memory.stat, the ChatGPT answered: In short, There are 28 entries in bytes and 37 entries in pages. ``` Based on the list provided, here are the counts for each: ### Entries in Bytes There are 28 entries in bytes: 1. anon 2. file 3. kernel 4. kernel_stack 5. pagetables 6. sec_pagetables 7. percpu 8. sock 9. vmalloc 10. shmem 11. zswap 12. zswapped 13. file_mapped 14. file_dirty 15. file_writeback 16. swapcached 17. anon_thp 18. file_thp 19. shmem_thp 20. inactive_anon 21. active_anon 22. inactive_file 23. active_file 24. unevictable 25. slab_reclaimable 26. slab_unreclaimable 27. slab 28. hugetlb ### Entries in Pages There are 37 entries in pages: 1. workingset_refault_anon 2. workingset_refault_file 3. workingset_activate_anon 4. workingset_activate_file 5. workingset_restore_anon 6. workingset_restore_file 7. workingset_nodereclaim 8. pgscan 9. pgsteal 10. pgscan_kswapd 11. pgscan_direct 12. pgscan_khugepaged 13. pgsteal_kswapd 14. pgsteal_direct 15. pgsteal_khugepaged 16. pgfault 17. pgmajfault 18. pgrefill 19. pgactivate 20. pgdeactivate 21. pglazyfree 22. pglazyfreed 23. swpin_zero 24. swpout_zero 25. zswpin 26. zswpout 27. zswpwb 28. thp_fault_alloc 29. thp_collapse_alloc 30. thp_swpout 31. thp_swpout_fallback 32. numa_pages_migrated 33. numa_pte_updates 34. numa_hint_faults 35. pgdemote_kswapd 36. pgdemote_direct 37. pgdemote_khugepaged ``` The above can have an easy alternative description > "the number of times khugepaged demoted a huge page" - ie. indicate that it > is an event counter instead, which is a plausible and likely more intuitive > definition anyway given that a "huge page" can plausibly be of different > sizes. With the key name and matching description, I'm not sure it's > violating the rule that all *sizes* are expressed in bytes. > > Thanks. >