* [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 4:22 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-14 4:22 UTC (permalink / raw) To: Andrew Morton; +Cc: Andi Kleen, LKML, linux-mm Export the following page flags in /proc/kpageflags, just in case they will be useful to someone: - PG_swapcache - PG_swapbacked - PG_mappedtodisk - PG_reserved - PG_private - PG_private_2 - PG_owner_priv_1 - PG_head - PG_tail - PG_compound - PG_unevictable - PG_mlocked - PG_poison Also add the following two pseudo page flags: - PG_MMAP: whether the page is memory mapped - PG_NOPAGE: whether the page is present This increases the total number of exported page flags to 25. Cc: Andi Kleen <andi@firstfloor.org> Cc: Matt Mackall <mpm@selenic.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> --- fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 81 insertions(+), 31 deletions(-) --- mm.orig/fs/proc/page.c +++ mm/fs/proc/page.c @@ -68,20 +68,86 @@ static const struct file_operations proc /* These macros are used to decouple internal flags from exported ones */ -#define KPF_LOCKED 0 -#define KPF_ERROR 1 -#define KPF_REFERENCED 2 -#define KPF_UPTODATE 3 -#define KPF_DIRTY 4 -#define KPF_LRU 5 -#define KPF_ACTIVE 6 -#define KPF_SLAB 7 -#define KPF_WRITEBACK 8 -#define KPF_RECLAIM 9 -#define KPF_BUDDY 10 +enum { + KPF_LOCKED, /* 0 */ + KPF_ERROR, /* 1 */ + KPF_REFERENCED, /* 2 */ + KPF_UPTODATE, /* 3 */ + KPF_DIRTY, /* 4 */ + KPF_LRU, /* 5 */ + KPF_ACTIVE, /* 6 */ + KPF_SLAB, /* 7 */ + KPF_WRITEBACK, /* 8 */ + KPF_RECLAIM, /* 9 */ + KPF_BUDDY, /* 10 */ + KPF_MMAP, /* 11 */ + KPF_SWAPCACHE, /* 12 */ + KPF_SWAPBACKED, /* 13 */ + KPF_MAPPEDTODISK, /* 14 */ + KPF_RESERVED, /* 15 */ + KPF_PRIVATE, /* 16 */ + KPF_PRIVATE2, /* 17 */ + KPF_OWNER_PRIVATE, /* 18 */ + KPF_COMPOUND_HEAD, /* 19 */ + KPF_COMPOUND_TAIL, /* 20 */ + KPF_UNEVICTABLE, /* 21 */ + KPF_MLOCKED, /* 22 */ + KPF_POISON, /* 23 */ + KPF_NOPAGE, /* 24 */ + KPF_NUM +}; #define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) +u64 get_uflags(struct page *page) +{ + unsigned long kflags; /* todo: use u64 when KPF_NUM grows beyond 32 */ + u64 uflags; + + if (!page) + return 1 << KPF_NOPAGE; + + kflags = page->flags; + uflags = 0; + + if (page_mapped(page)) + uflags |= 1 << KPF_MMAP; + + uflags |= kpf_copy_bit(kflags, KPF_LOCKED, PG_locked); + uflags |= kpf_copy_bit(kflags, KPF_ERROR, PG_error); + uflags |= kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced); + uflags |= kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate); + uflags |= kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty); + uflags |= kpf_copy_bit(kflags, KPF_LRU, PG_lru) ; + uflags |= kpf_copy_bit(kflags, KPF_ACTIVE, PG_active); + uflags |= kpf_copy_bit(kflags, KPF_SLAB, PG_slab); + uflags |= kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback); + uflags |= kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim); + uflags |= kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); + uflags |= kpf_copy_bit(kflags, KPF_SWAPCACHE, PG_swapcache); + uflags |= kpf_copy_bit(kflags, KPF_SWAPBACKED, PG_swapbacked); + uflags |= kpf_copy_bit(kflags, KPF_MAPPEDTODISK, PG_mappedtodisk); + uflags |= kpf_copy_bit(kflags, KPF_RESERVED, PG_reserved); + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE, PG_private); + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE2, PG_private_2); + uflags |= kpf_copy_bit(kflags, KPF_OWNER_PRIVATE, PG_owner_priv_1); +#ifdef CONFIG_PAGEFLAGS_EXTENDED + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND_HEAD, PG_head); + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND_TAIL, PG_tail); +#else + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND_HEAD, PG_compound); +#endif +#ifdef CONFIG_UNEVICTABLE_LRU + uflags |= kpf_copy_bit(kflags, KPF_UNEVICTABLE, PG_unevictable); + uflags |= kpf_copy_bit(kflags, KPF_MLOCKED, PG_mlocked); +#endif +#ifdef CONFIG_MEMORY_FAILURE + uflags |= kpf_copy_bit(kflags, KPF_POISON, PG_poison); +#endif + + return uflags; +}; + static ssize_t kpageflags_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { @@ -90,7 +156,6 @@ static ssize_t kpageflags_read(struct fi unsigned long src = *ppos; unsigned long pfn; ssize_t ret = 0; - u64 kflags, uflags; pfn = src / KPMSIZE; count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); @@ -98,32 +163,17 @@ static ssize_t kpageflags_read(struct fi return -EINVAL; while (count > 0) { - ppage = NULL; if (pfn_valid(pfn)) ppage = pfn_to_page(pfn); - pfn++; - if (!ppage) - kflags = 0; else - kflags = ppage->flags; + ppage = NULL; - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); - - if (put_user(uflags, out++)) { + if (put_user(get_uflags(ppage), out)) { ret = -EFAULT; break; } - + out++; + pfn++; count -= KPMSIZE; } ^ permalink raw reply [flat|nested] 44+ messages in thread
* [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 4:22 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-14 4:22 UTC (permalink / raw) To: Andrew Morton; +Cc: Andi Kleen, LKML, linux-mm Export the following page flags in /proc/kpageflags, just in case they will be useful to someone: - PG_swapcache - PG_swapbacked - PG_mappedtodisk - PG_reserved - PG_private - PG_private_2 - PG_owner_priv_1 - PG_head - PG_tail - PG_compound - PG_unevictable - PG_mlocked - PG_poison Also add the following two pseudo page flags: - PG_MMAP: whether the page is memory mapped - PG_NOPAGE: whether the page is present This increases the total number of exported page flags to 25. Cc: Andi Kleen <andi@firstfloor.org> Cc: Matt Mackall <mpm@selenic.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> --- fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 81 insertions(+), 31 deletions(-) --- mm.orig/fs/proc/page.c +++ mm/fs/proc/page.c @@ -68,20 +68,86 @@ static const struct file_operations proc /* These macros are used to decouple internal flags from exported ones */ -#define KPF_LOCKED 0 -#define KPF_ERROR 1 -#define KPF_REFERENCED 2 -#define KPF_UPTODATE 3 -#define KPF_DIRTY 4 -#define KPF_LRU 5 -#define KPF_ACTIVE 6 -#define KPF_SLAB 7 -#define KPF_WRITEBACK 8 -#define KPF_RECLAIM 9 -#define KPF_BUDDY 10 +enum { + KPF_LOCKED, /* 0 */ + KPF_ERROR, /* 1 */ + KPF_REFERENCED, /* 2 */ + KPF_UPTODATE, /* 3 */ + KPF_DIRTY, /* 4 */ + KPF_LRU, /* 5 */ + KPF_ACTIVE, /* 6 */ + KPF_SLAB, /* 7 */ + KPF_WRITEBACK, /* 8 */ + KPF_RECLAIM, /* 9 */ + KPF_BUDDY, /* 10 */ + KPF_MMAP, /* 11 */ + KPF_SWAPCACHE, /* 12 */ + KPF_SWAPBACKED, /* 13 */ + KPF_MAPPEDTODISK, /* 14 */ + KPF_RESERVED, /* 15 */ + KPF_PRIVATE, /* 16 */ + KPF_PRIVATE2, /* 17 */ + KPF_OWNER_PRIVATE, /* 18 */ + KPF_COMPOUND_HEAD, /* 19 */ + KPF_COMPOUND_TAIL, /* 20 */ + KPF_UNEVICTABLE, /* 21 */ + KPF_MLOCKED, /* 22 */ + KPF_POISON, /* 23 */ + KPF_NOPAGE, /* 24 */ + KPF_NUM +}; #define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) +u64 get_uflags(struct page *page) +{ + unsigned long kflags; /* todo: use u64 when KPF_NUM grows beyond 32 */ + u64 uflags; + + if (!page) + return 1 << KPF_NOPAGE; + + kflags = page->flags; + uflags = 0; + + if (page_mapped(page)) + uflags |= 1 << KPF_MMAP; + + uflags |= kpf_copy_bit(kflags, KPF_LOCKED, PG_locked); + uflags |= kpf_copy_bit(kflags, KPF_ERROR, PG_error); + uflags |= kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced); + uflags |= kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate); + uflags |= kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty); + uflags |= kpf_copy_bit(kflags, KPF_LRU, PG_lru) ; + uflags |= kpf_copy_bit(kflags, KPF_ACTIVE, PG_active); + uflags |= kpf_copy_bit(kflags, KPF_SLAB, PG_slab); + uflags |= kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback); + uflags |= kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim); + uflags |= kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); + uflags |= kpf_copy_bit(kflags, KPF_SWAPCACHE, PG_swapcache); + uflags |= kpf_copy_bit(kflags, KPF_SWAPBACKED, PG_swapbacked); + uflags |= kpf_copy_bit(kflags, KPF_MAPPEDTODISK, PG_mappedtodisk); + uflags |= kpf_copy_bit(kflags, KPF_RESERVED, PG_reserved); + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE, PG_private); + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE2, PG_private_2); + uflags |= kpf_copy_bit(kflags, KPF_OWNER_PRIVATE, PG_owner_priv_1); +#ifdef CONFIG_PAGEFLAGS_EXTENDED + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND_HEAD, PG_head); + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND_TAIL, PG_tail); +#else + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND_HEAD, PG_compound); +#endif +#ifdef CONFIG_UNEVICTABLE_LRU + uflags |= kpf_copy_bit(kflags, KPF_UNEVICTABLE, PG_unevictable); + uflags |= kpf_copy_bit(kflags, KPF_MLOCKED, PG_mlocked); +#endif +#ifdef CONFIG_MEMORY_FAILURE + uflags |= kpf_copy_bit(kflags, KPF_POISON, PG_poison); +#endif + + return uflags; +}; + static ssize_t kpageflags_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { @@ -90,7 +156,6 @@ static ssize_t kpageflags_read(struct fi unsigned long src = *ppos; unsigned long pfn; ssize_t ret = 0; - u64 kflags, uflags; pfn = src / KPMSIZE; count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); @@ -98,32 +163,17 @@ static ssize_t kpageflags_read(struct fi return -EINVAL; while (count > 0) { - ppage = NULL; if (pfn_valid(pfn)) ppage = pfn_to_page(pfn); - pfn++; - if (!ppage) - kflags = 0; else - kflags = ppage->flags; + ppage = NULL; - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); - - if (put_user(uflags, out++)) { + if (put_user(get_uflags(ppage), out)) { ret = -EFAULT; break; } - + out++; + pfn++; count -= KPMSIZE; } -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 4:22 ` Wu Fengguang (?) @ 2009-04-14 4:36 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-14 4:36 UTC (permalink / raw) To: Andrew Morton; +Cc: Andi Kleen, LKML, linux-mm [-- Attachment #1: Type: text/plain, Size: 5586 bytes --] On Tue, Apr 14, 2009 at 12:22:31PM +0800, Wu Fengguang wrote: > Export the following page flags in /proc/kpageflags, > just in case they will be useful to someone: > > - PG_swapcache > - PG_swapbacked > - PG_mappedtodisk > - PG_reserved > - PG_private > - PG_private_2 > - PG_owner_priv_1 > > - PG_head > - PG_tail > - PG_compound > > - PG_unevictable > - PG_mlocked > > - PG_poison > > Also add the following two pseudo page flags: > > - PG_MMAP: whether the page is memory mapped > - PG_NOPAGE: whether the page is present > > This increases the total number of exported page flags to 25. And here are two simple tools utilizing the exported page flags: # ./page-types flags page-count MB symbolic-flags long-symbolic-flags 0x000000 472521 1845 _________________________ 0x000020 1 0 _____l___________________ lru 0x000028 2516 9 ___U_l___________________ uptodate,lru 0x00002c 5209 20 __RU_l___________________ referenced,uptodate,lru 0x000068 234 0 ___U_lA__________________ uptodate,lru,active 0x00006c 981 3 __RU_lA__________________ referenced,uptodate,lru,active 0x000228 49 0 ___U_l___x_______________ uptodate,lru,reclaim 0x000400 547 2 __________B______________ buddy 0x000804 1 0 __R________m_____________ referenced,mmap 0x000828 1073 4 ___U_l_____m_____________ uptodate,lru,mmap 0x00082c 318 1 __RU_l_____m_____________ referenced,uptodate,lru,mmap 0x000868 235 0 ___U_lA____m_____________ uptodate,lru,active,mmap 0x00086c 822 3 __RU_lA____m_____________ referenced,uptodate,lru,active,mmap 0x000880 1510 5 _______S___m_____________ slab,mmap 0x0008c0 49 0 ______AS___m_____________ active,slab,mmap 0x002078 1 0 ___UDlA______b___________ uptodate,dirty,lru,active,swapbacked 0x00207c 17 0 __RUDlA______b___________ referenced,uptodate,dirty,lru,active,swapbacked 0x002808 10 0 ___U_______m_b___________ uptodate,mmap,swapbacked 0x002868 3296 12 ___U_lA____m_b___________ uptodate,lru,active,mmap,swapbacked 0x00286c 25 0 __RU_lA____m_b___________ referenced,uptodate,lru,active,mmap,swapbacked 0x002878 2 0 ___UDlA____m_b___________ uptodate,dirty,lru,active,mmap,swapbacked 0x008000 19247 75 _______________r_________ reserved 0x080000 15 0 ___________________H_____ head 0x080014 1 0 __R_D______________H_____ referenced,dirty,head 0x080880 915 3 _______S___m_______H_____ slab,mmap,head 0x0808c0 60 0 ______AS___m_______H_____ active,slab,mmap,head 0x100000 4309 16 ____________________T____ tail 0x100014 4 0 __R_D_______________T____ referenced,dirty,tail total 513968 2007 To show the compound tail pages: # ./page-areas 0x100000 offset len KB 3089 3 12KB 487441 7 28KB 487449 7 28KB 487457 7 28KB 487465 7 28KB 487473 7 28KB 487481 7 28KB 487489 7 28KB 487497 7 28KB 487505 7 28KB 487513 7 28KB 487521 7 28KB 487529 7 28KB 487537 7 28KB 487545 7 28KB 487553 7 28KB 487561 7 28KB 487569 7 28KB 487577 7 28KB 487585 7 28KB 487593 7 28KB 487617 7 28KB 487627 1 4KB 487629 1 4KB 487633 7 28KB 487641 7 28KB 487649 7 28KB 487657 7 28KB 487665 7 28KB 487673 7 28KB 487681 7 28KB 487689 7 28KB 487697 7 28KB 487705 7 28KB 487713 7 28KB 487721 7 28KB 487729 7 28KB 487737 7 28KB 487745 7 28KB 487753 7 28KB 487761 7 28KB 487769 7 28KB 487777 7 28KB 487785 7 28KB 487793 7 28KB 487801 7 28KB 487809 7 28KB 487817 7 28KB 487825 7 28KB 487853 3 12KB 487865 7 28KB 487873 3 12KB 487893 3 12KB 487897 3 12KB 487901 3 12KB 487905 3 12KB 487909 3 12KB 487929 7 28KB 487937 7 28KB 487945 7 28KB 493569 3 12KB 493573 1 4KB 493575 1 4KB 493585 7 28KB 493593 3 12KB 493597 3 12KB 493601 7 28KB 493609 7 28KB 493617 7 28KB 493625 1 4KB 493633 7 28KB 493641 3 12KB 493645 3 12KB [snip] Thanks, Fengguang [-- Attachment #2: page-types.c --] [-- Type: text/x-csrc, Size: 1635 bytes --] #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdint.h> #include <sys/types.h> #include <sys/errno.h> #include <sys/fcntl.h> #include "pagemap.h" int main(int argc, char *argv[]) { static char kpageflags_name[] = "/proc/kpageflags"; unsigned long i; uint64_t flags; int fd; fd = open(kpageflags_name, O_RDONLY); if (fd < 0) { perror(kpageflags_name); exit(1); } nr_pages = read(fd, kpageflags, sizeof(kpageflags)); if (nr_pages <= 0) { perror(kpageflags_name); exit(2); } if (nr_pages % KPF_BYTES != 0) { fprintf(stderr, "%s: partial read: %lu bytes\n", argv[0], nr_pages); exit(3); } nr_pages = nr_pages / KPF_BYTES; for (i = 0; i < nr_pages; i++) { flags = kpageflags[i]; if (flags >= ARRAY_SIZE(page_count)) { static int warned = 0; if (!warned) { warned = 1; fprintf(stderr, "%s: flags overflow: 0x%lx >= 0x%lx\n", argv[0], flags, ARRAY_SIZE(page_count)); fprintf(stderr, "Either the kernel is buggy(<=2.6.28), " "or I'm too old to recognize new flags.\n\n"); } flags = ARRAY_SIZE(page_count) - 1; } page_count[flags]++; } #if 0 for (i = 0; i < ARRAY_SIZE(page_flag_names); i++) { printf("%s ", page_flag_names[i]); } #endif printf(" flags\tpage-count MB symbolic-flags long-symbolic-flags\n"); for (i = 0; i < ARRAY_SIZE(page_count); i++) { if (page_count[i]) printf("0x%06lx\t%10lu %8lu %s %s\n", i, page_count[i], pages2mb(page_count[i]), page_flag_name(i), page_flag_longname(i)); } printf(" total\t%10lu %8lu\n", nr_pages, pages2mb(nr_pages)); return 0; } [-- Attachment #3: pagemap.h --] [-- Type: text/x-chdr, Size: 2824 bytes --] #define KPF_BYTES 8 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) /* copied from kpageflags_read() */ enum { KPF_LOCKED, /* 0 */ KPF_ERROR, /* 1 */ KPF_REFERENCED, /* 2 */ KPF_UPTODATE, /* 3 */ KPF_DIRTY, /* 4 */ KPF_LRU, /* 5 */ KPF_ACTIVE, /* 6 */ KPF_SLAB, /* 7 */ KPF_WRITEBACK, /* 8 */ KPF_RECLAIM, /* 9 */ KPF_BUDDY, /* 10 */ KPF_MMAP, /* 11 */ KPF_SWAPCACHE, /* 12 */ KPF_SWAPBACKED, /* 13 */ KPF_MAPPEDTODISK, /* 14 */ KPF_RESERVED, /* 15 */ KPF_PRIVATE, /* 16 */ KPF_PRIVATE2, /* 17 */ KPF_OWNER_PRIVATE, /* 18 */ KPF_COMPOUND_HEAD, /* 19 */ KPF_COMPOUND_TAIL, /* 20 */ KPF_UNEVICTABLE, /* 21 */ KPF_MLOCKED, /* 22 */ KPF_POISON, /* 23 */ KPF_NOPAGE, /* 24 */ KPF_NUM }; static char *page_flag_names[] = { [KPF_LOCKED] = "L:locked", [KPF_ERROR] = "E:error", [KPF_REFERENCED] = "R:referenced", [KPF_UPTODATE] = "U:uptodate", [KPF_DIRTY] = "D:dirty", [KPF_LRU] = "l:lru", [KPF_ACTIVE] = "A:active", [KPF_SLAB] = "S:slab", [KPF_WRITEBACK] = "W:writeback", [KPF_RECLAIM] = "x:reclaim", [KPF_BUDDY] = "B:buddy", [KPF_RESERVED] = "r:reserved", [KPF_SWAPCACHE] = "c:swapcache", [KPF_SWAPBACKED] = "b:swapbacked", [KPF_MAPPEDTODISK] = "d:mappedtodisk", [KPF_PRIVATE] = "P:private", [KPF_PRIVATE2] = "p:private_2", [KPF_OWNER_PRIVATE] = "O:owner_private", [KPF_COMPOUND_HEAD] = "H:head", [KPF_COMPOUND_TAIL] = "T:tail", [KPF_UNEVICTABLE] = "u:unevictable", [KPF_MLOCKED] = "M:mlocked", [KPF_MMAP] = "m:mmap", [KPF_POISON] = "X:poison", [KPF_NOPAGE] = "n:nopage", }; static unsigned long page_count[(1 << KPF_NUM)]; static unsigned long nr_pages; static uint64_t kpageflags[KPF_BYTES * (16<<20)]; /* 64GB */ char *page_flag_name(uint64_t flags) { int i; static char buf[64]; for (i = 0; i < ARRAY_SIZE(page_flag_names); i++) buf[i] = (flags & (1 << i)) ? page_flag_names[i][0] : '_'; return buf; } char *page_flag_longname(uint64_t flags) { int i, n; static char buf[1024]; for (i = 0, n = 0; i < ARRAY_SIZE(page_flag_names); i++) if (flags & (1<<i)) n += snprintf(buf + n, sizeof(buf) - n, "%s,", page_flag_names[i] + 2); if (n) n--; buf[n] = '\0'; return buf; } static unsigned long pages2kb(unsigned long pages) { return (pages * getpagesize()) >> 10; } static unsigned long pages2mb(unsigned long pages) { return (pages * getpagesize()) >> 20; } [-- Attachment #4: Makefile --] [-- Type: text/plain, Size: 169 bytes --] BINS = page-types page-areas all: $(BINS) page-types: page-types.c pagemap.h gcc -g -o $@ $< page-areas: page-areas.c pagemap.h gcc -g -o $@ $< clean: rm $(BINS) [-- Attachment #5: page-areas.c --] [-- Type: text/x-csrc, Size: 1443 bytes --] #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdint.h> #include <sys/types.h> #include <sys/errno.h> #include <sys/fcntl.h> #include "pagemap.h" static void add_index(unsigned long index) { static unsigned long offset, len; if (index == offset + len) len++; else { if (len) printf("%10lu %8lu %8luKB\n", offset, len, pages2kb(len)); offset = index; len = 1; } } static void usage(const char *prog) { printf("Usage: %s page_flags\n", prog); } int main(int argc, char *argv[]) { static char kpageflags_name[] = "/proc/kpageflags"; unsigned long match_flags, match_exact; unsigned long i; char *p; int fd; if (argc < 2) { usage(argv[0]); exit(1); } match_exact = 0; p = argv[1]; if (p[0] == '=') { match_exact = 1; p++; } match_flags = strtol(p, 0, 16); fd = open(kpageflags_name, O_RDONLY); if (fd < 0) { perror(kpageflags_name); exit(1); } nr_pages = read(fd, kpageflags, sizeof(kpageflags)); if (nr_pages <= 0) { perror(kpageflags_name); exit(2); } if (nr_pages % KPF_BYTES != 0) { fprintf(stderr, "%s: partial read: %lu bytes\n", argv[0], nr_pages); exit(3); } nr_pages = nr_pages / KPF_BYTES; printf(" offset len KB\n"); for (i = 0; i < nr_pages; i++) { if (!match_exact && ((kpageflags[i] & match_flags) == match_flags) || (match_exact && kpageflags[i] == match_flags)) add_index(i); } add_index(0); return 0; } ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 4:22 ` Wu Fengguang @ 2009-04-14 4:37 ` KOSAKI Motohiro -1 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-14 4:37 UTC (permalink / raw) To: Wu Fengguang; +Cc: kosaki.motohiro, Andrew Morton, Andi Kleen, LKML, linux-mm > Export the following page flags in /proc/kpageflags, > just in case they will be useful to someone: > > - PG_swapcache > - PG_swapbacked > - PG_mappedtodisk > - PG_reserved > - PG_private > - PG_private_2 > - PG_owner_priv_1 > > - PG_head > - PG_tail > - PG_compound > > - PG_unevictable > - PG_mlocked > > - PG_poison Sorry, NAK this. We shouldn't expose internal flags. please choice useful flags only. > > Also add the following two pseudo page flags: > > - PG_MMAP: whether the page is memory mapped > - PG_NOPAGE: whether the page is present > > This increases the total number of exported page flags to 25. > > Cc: Andi Kleen <andi@firstfloor.org> > Cc: Matt Mackall <mpm@selenic.com> > Cc: Alexey Dobriyan <adobriyan@gmail.com> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > --- > fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- > 1 file changed, 81 insertions(+), 31 deletions(-) > > --- mm.orig/fs/proc/page.c > +++ mm/fs/proc/page.c > @@ -68,20 +68,86 @@ static const struct file_operations proc > > /* These macros are used to decouple internal flags from exported ones */ > > -#define KPF_LOCKED 0 > -#define KPF_ERROR 1 > -#define KPF_REFERENCED 2 > -#define KPF_UPTODATE 3 > -#define KPF_DIRTY 4 > -#define KPF_LRU 5 > -#define KPF_ACTIVE 6 > -#define KPF_SLAB 7 > -#define KPF_WRITEBACK 8 > -#define KPF_RECLAIM 9 > -#define KPF_BUDDY 10 > +enum { > + KPF_LOCKED, /* 0 */ > + KPF_ERROR, /* 1 */ > + KPF_REFERENCED, /* 2 */ > + KPF_UPTODATE, /* 3 */ > + KPF_DIRTY, /* 4 */ > + KPF_LRU, /* 5 */ > + KPF_ACTIVE, /* 6 */ > + KPF_SLAB, /* 7 */ > + KPF_WRITEBACK, /* 8 */ > + KPF_RECLAIM, /* 9 */ > + KPF_BUDDY, /* 10 */ > + KPF_MMAP, /* 11 */ > + KPF_SWAPCACHE, /* 12 */ > + KPF_SWAPBACKED, /* 13 */ > + KPF_MAPPEDTODISK, /* 14 */ > + KPF_RESERVED, /* 15 */ > + KPF_PRIVATE, /* 16 */ > + KPF_PRIVATE2, /* 17 */ > + KPF_OWNER_PRIVATE, /* 18 */ > + KPF_COMPOUND_HEAD, /* 19 */ > + KPF_COMPOUND_TAIL, /* 20 */ > + KPF_UNEVICTABLE, /* 21 */ > + KPF_MLOCKED, /* 22 */ > + KPF_POISON, /* 23 */ > + KPF_NOPAGE, /* 24 */ > + KPF_NUM > +}; this is userland export value. then enum is wrong idea. explicit name-number relationship is better. it prevent unintetional ABI break. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 4:37 ` KOSAKI Motohiro 0 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-14 4:37 UTC (permalink / raw) To: Wu Fengguang; +Cc: kosaki.motohiro, Andrew Morton, Andi Kleen, LKML, linux-mm > Export the following page flags in /proc/kpageflags, > just in case they will be useful to someone: > > - PG_swapcache > - PG_swapbacked > - PG_mappedtodisk > - PG_reserved > - PG_private > - PG_private_2 > - PG_owner_priv_1 > > - PG_head > - PG_tail > - PG_compound > > - PG_unevictable > - PG_mlocked > > - PG_poison Sorry, NAK this. We shouldn't expose internal flags. please choice useful flags only. > > Also add the following two pseudo page flags: > > - PG_MMAP: whether the page is memory mapped > - PG_NOPAGE: whether the page is present > > This increases the total number of exported page flags to 25. > > Cc: Andi Kleen <andi@firstfloor.org> > Cc: Matt Mackall <mpm@selenic.com> > Cc: Alexey Dobriyan <adobriyan@gmail.com> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > --- > fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- > 1 file changed, 81 insertions(+), 31 deletions(-) > > --- mm.orig/fs/proc/page.c > +++ mm/fs/proc/page.c > @@ -68,20 +68,86 @@ static const struct file_operations proc > > /* These macros are used to decouple internal flags from exported ones */ > > -#define KPF_LOCKED 0 > -#define KPF_ERROR 1 > -#define KPF_REFERENCED 2 > -#define KPF_UPTODATE 3 > -#define KPF_DIRTY 4 > -#define KPF_LRU 5 > -#define KPF_ACTIVE 6 > -#define KPF_SLAB 7 > -#define KPF_WRITEBACK 8 > -#define KPF_RECLAIM 9 > -#define KPF_BUDDY 10 > +enum { > + KPF_LOCKED, /* 0 */ > + KPF_ERROR, /* 1 */ > + KPF_REFERENCED, /* 2 */ > + KPF_UPTODATE, /* 3 */ > + KPF_DIRTY, /* 4 */ > + KPF_LRU, /* 5 */ > + KPF_ACTIVE, /* 6 */ > + KPF_SLAB, /* 7 */ > + KPF_WRITEBACK, /* 8 */ > + KPF_RECLAIM, /* 9 */ > + KPF_BUDDY, /* 10 */ > + KPF_MMAP, /* 11 */ > + KPF_SWAPCACHE, /* 12 */ > + KPF_SWAPBACKED, /* 13 */ > + KPF_MAPPEDTODISK, /* 14 */ > + KPF_RESERVED, /* 15 */ > + KPF_PRIVATE, /* 16 */ > + KPF_PRIVATE2, /* 17 */ > + KPF_OWNER_PRIVATE, /* 18 */ > + KPF_COMPOUND_HEAD, /* 19 */ > + KPF_COMPOUND_TAIL, /* 20 */ > + KPF_UNEVICTABLE, /* 21 */ > + KPF_MLOCKED, /* 22 */ > + KPF_POISON, /* 23 */ > + KPF_NOPAGE, /* 24 */ > + KPF_NUM > +}; this is userland export value. then enum is wrong idea. explicit name-number relationship is better. it prevent unintetional ABI break. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 4:37 ` KOSAKI Motohiro @ 2009-04-14 6:41 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-14 6:41 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andrew Morton, Andi Kleen, LKML, linux-mm On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > Export the following page flags in /proc/kpageflags, > > just in case they will be useful to someone: > > > > - PG_swapcache > > - PG_swapbacked > > - PG_mappedtodisk > > - PG_reserved > > - PG_private > > - PG_private_2 > > - PG_owner_priv_1 > > > > - PG_head > > - PG_tail > > - PG_compound > > > > - PG_unevictable > > - PG_mlocked > > > > - PG_poison > > Sorry, NAK this. > We shouldn't expose internal flags. please choice useful flags only. OK. So are there anyone interested in any of these flags? Thanks! My rational to export most page flags is that hopefully they could help debugging kernel at some random situations.. > > Also add the following two pseudo page flags: > > > > - PG_MMAP: whether the page is memory mapped > > - PG_NOPAGE: whether the page is present > > > > This increases the total number of exported page flags to 25. > > > > Cc: Andi Kleen <andi@firstfloor.org> > > Cc: Matt Mackall <mpm@selenic.com> > > Cc: Alexey Dobriyan <adobriyan@gmail.com> > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > > --- > > fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- > > 1 file changed, 81 insertions(+), 31 deletions(-) > > > > --- mm.orig/fs/proc/page.c > > +++ mm/fs/proc/page.c > > @@ -68,20 +68,86 @@ static const struct file_operations proc > > > > /* These macros are used to decouple internal flags from exported ones */ > > > > -#define KPF_LOCKED 0 > > -#define KPF_ERROR 1 > > -#define KPF_REFERENCED 2 > > -#define KPF_UPTODATE 3 > > -#define KPF_DIRTY 4 > > -#define KPF_LRU 5 > > -#define KPF_ACTIVE 6 > > -#define KPF_SLAB 7 > > -#define KPF_WRITEBACK 8 > > -#define KPF_RECLAIM 9 > > -#define KPF_BUDDY 10 > > +enum { > > + KPF_LOCKED, /* 0 */ > > + KPF_ERROR, /* 1 */ > > + KPF_REFERENCED, /* 2 */ > > + KPF_UPTODATE, /* 3 */ > > + KPF_DIRTY, /* 4 */ > > + KPF_LRU, /* 5 */ > > + KPF_ACTIVE, /* 6 */ > > + KPF_SLAB, /* 7 */ > > + KPF_WRITEBACK, /* 8 */ > > + KPF_RECLAIM, /* 9 */ > > + KPF_BUDDY, /* 10 */ > > + KPF_MMAP, /* 11 */ > > + KPF_SWAPCACHE, /* 12 */ > > + KPF_SWAPBACKED, /* 13 */ > > + KPF_MAPPEDTODISK, /* 14 */ > > + KPF_RESERVED, /* 15 */ > > + KPF_PRIVATE, /* 16 */ > > + KPF_PRIVATE2, /* 17 */ > > + KPF_OWNER_PRIVATE, /* 18 */ > > + KPF_COMPOUND_HEAD, /* 19 */ > > + KPF_COMPOUND_TAIL, /* 20 */ > > + KPF_UNEVICTABLE, /* 21 */ > > + KPF_MLOCKED, /* 22 */ > > + KPF_POISON, /* 23 */ > > + KPF_NOPAGE, /* 24 */ > > + KPF_NUM > > +}; > > this is userland export value. then enum is wrong idea. > explicit name-number relationship is better. it prevent unintetional > ABI break. Right, that's the reason I add the /* number */ comments. Anyway, it would be better to use explicit #defines. Thanks, Fengguang ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 6:41 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-14 6:41 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andrew Morton, Andi Kleen, LKML, linux-mm On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > Export the following page flags in /proc/kpageflags, > > just in case they will be useful to someone: > > > > - PG_swapcache > > - PG_swapbacked > > - PG_mappedtodisk > > - PG_reserved > > - PG_private > > - PG_private_2 > > - PG_owner_priv_1 > > > > - PG_head > > - PG_tail > > - PG_compound > > > > - PG_unevictable > > - PG_mlocked > > > > - PG_poison > > Sorry, NAK this. > We shouldn't expose internal flags. please choice useful flags only. OK. So are there anyone interested in any of these flags? Thanks! My rational to export most page flags is that hopefully they could help debugging kernel at some random situations.. > > Also add the following two pseudo page flags: > > > > - PG_MMAP: whether the page is memory mapped > > - PG_NOPAGE: whether the page is present > > > > This increases the total number of exported page flags to 25. > > > > Cc: Andi Kleen <andi@firstfloor.org> > > Cc: Matt Mackall <mpm@selenic.com> > > Cc: Alexey Dobriyan <adobriyan@gmail.com> > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > > --- > > fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- > > 1 file changed, 81 insertions(+), 31 deletions(-) > > > > --- mm.orig/fs/proc/page.c > > +++ mm/fs/proc/page.c > > @@ -68,20 +68,86 @@ static const struct file_operations proc > > > > /* These macros are used to decouple internal flags from exported ones */ > > > > -#define KPF_LOCKED 0 > > -#define KPF_ERROR 1 > > -#define KPF_REFERENCED 2 > > -#define KPF_UPTODATE 3 > > -#define KPF_DIRTY 4 > > -#define KPF_LRU 5 > > -#define KPF_ACTIVE 6 > > -#define KPF_SLAB 7 > > -#define KPF_WRITEBACK 8 > > -#define KPF_RECLAIM 9 > > -#define KPF_BUDDY 10 > > +enum { > > + KPF_LOCKED, /* 0 */ > > + KPF_ERROR, /* 1 */ > > + KPF_REFERENCED, /* 2 */ > > + KPF_UPTODATE, /* 3 */ > > + KPF_DIRTY, /* 4 */ > > + KPF_LRU, /* 5 */ > > + KPF_ACTIVE, /* 6 */ > > + KPF_SLAB, /* 7 */ > > + KPF_WRITEBACK, /* 8 */ > > + KPF_RECLAIM, /* 9 */ > > + KPF_BUDDY, /* 10 */ > > + KPF_MMAP, /* 11 */ > > + KPF_SWAPCACHE, /* 12 */ > > + KPF_SWAPBACKED, /* 13 */ > > + KPF_MAPPEDTODISK, /* 14 */ > > + KPF_RESERVED, /* 15 */ > > + KPF_PRIVATE, /* 16 */ > > + KPF_PRIVATE2, /* 17 */ > > + KPF_OWNER_PRIVATE, /* 18 */ > > + KPF_COMPOUND_HEAD, /* 19 */ > > + KPF_COMPOUND_TAIL, /* 20 */ > > + KPF_UNEVICTABLE, /* 21 */ > > + KPF_MLOCKED, /* 22 */ > > + KPF_POISON, /* 23 */ > > + KPF_NOPAGE, /* 24 */ > > + KPF_NUM > > +}; > > this is userland export value. then enum is wrong idea. > explicit name-number relationship is better. it prevent unintetional > ABI break. Right, that's the reason I add the /* number */ comments. Anyway, it would be better to use explicit #defines. Thanks, Fengguang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 6:41 ` Wu Fengguang @ 2009-04-14 6:54 ` KOSAKI Motohiro -1 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-14 6:54 UTC (permalink / raw) To: Wu Fengguang; +Cc: kosaki.motohiro, Andrew Morton, Andi Kleen, LKML, linux-mm Hi > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > Export the following page flags in /proc/kpageflags, > > > just in case they will be useful to someone: > > > > > > - PG_swapcache > > > - PG_swapbacked > > > - PG_mappedtodisk > > > - PG_reserved > > > - PG_private > > > - PG_private_2 > > > - PG_owner_priv_1 > > > > > > - PG_head > > > - PG_tail > > > - PG_compound > > > > > > - PG_unevictable > > > - PG_mlocked > > > > > > - PG_poison > > > > Sorry, NAK this. > > We shouldn't expose internal flags. please choice useful flags only. > > OK. So are there anyone interested in any of these flags? Thanks! > > My rational to export most page flags is that hopefully they could > help debugging kernel at some random situations.. I think, > > > - PG_mappedtodisk > > > - PG_reserved > > > - PG_private > > > - PG_private_2 > > > - PG_owner_priv_1 > > > > > > - PG_head > > > - PG_tail > > > > > > - PG_unevictable > > > - PG_mlocked this 9 flags shouldn't exported. I can't imazine administrator use what purpose those flags. > > > - PG_swapcache > > > - PG_swapbacked > > > - PG_poison > > > - PG_compound I can agree this 4 flags. However pagemap lack's hugepage considering. if PG_compound exporting, we need more work. > > > > Also add the following two pseudo page flags: > > > > > > - PG_MMAP: whether the page is memory mapped hm, I can agree it. > > > - PG_NOPAGE: whether the page is present PM_NOT_PRESENT isn't enough? > > > > > > This increases the total number of exported page flags to 25. > > > > > > Cc: Andi Kleen <andi@firstfloor.org> > > > Cc: Matt Mackall <mpm@selenic.com> > > > Cc: Alexey Dobriyan <adobriyan@gmail.com> > > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > > > --- > > > fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- > > > 1 file changed, 81 insertions(+), 31 deletions(-) > > > > > > --- mm.orig/fs/proc/page.c > > > +++ mm/fs/proc/page.c > > > @@ -68,20 +68,86 @@ static const struct file_operations proc > > > > > > /* These macros are used to decouple internal flags from exported ones */ > > > > > > -#define KPF_LOCKED 0 > > > -#define KPF_ERROR 1 > > > -#define KPF_REFERENCED 2 > > > -#define KPF_UPTODATE 3 > > > -#define KPF_DIRTY 4 > > > -#define KPF_LRU 5 > > > -#define KPF_ACTIVE 6 > > > -#define KPF_SLAB 7 > > > -#define KPF_WRITEBACK 8 > > > -#define KPF_RECLAIM 9 > > > -#define KPF_BUDDY 10 > > > +enum { > > > + KPF_LOCKED, /* 0 */ > > > + KPF_ERROR, /* 1 */ > > > + KPF_REFERENCED, /* 2 */ > > > + KPF_UPTODATE, /* 3 */ > > > + KPF_DIRTY, /* 4 */ > > > + KPF_LRU, /* 5 */ > > > + KPF_ACTIVE, /* 6 */ > > > + KPF_SLAB, /* 7 */ > > > + KPF_WRITEBACK, /* 8 */ > > > + KPF_RECLAIM, /* 9 */ > > > + KPF_BUDDY, /* 10 */ > > > + KPF_MMAP, /* 11 */ > > > + KPF_SWAPCACHE, /* 12 */ > > > + KPF_SWAPBACKED, /* 13 */ > > > + KPF_MAPPEDTODISK, /* 14 */ > > > + KPF_RESERVED, /* 15 */ > > > + KPF_PRIVATE, /* 16 */ > > > + KPF_PRIVATE2, /* 17 */ > > > + KPF_OWNER_PRIVATE, /* 18 */ > > > + KPF_COMPOUND_HEAD, /* 19 */ > > > + KPF_COMPOUND_TAIL, /* 20 */ > > > + KPF_UNEVICTABLE, /* 21 */ > > > + KPF_MLOCKED, /* 22 */ > > > + KPF_POISON, /* 23 */ > > > + KPF_NOPAGE, /* 24 */ > > > + KPF_NUM > > > +}; > > > > this is userland export value. then enum is wrong idea. > > explicit name-number relationship is better. it prevent unintetional > > ABI break. > > Right, that's the reason I add the /* number */ comments. > Anyway, it would be better to use explicit #defines. > > Thanks, > Fengguang > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 6:54 ` KOSAKI Motohiro 0 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-14 6:54 UTC (permalink / raw) To: Wu Fengguang; +Cc: kosaki.motohiro, Andrew Morton, Andi Kleen, LKML, linux-mm Hi > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > Export the following page flags in /proc/kpageflags, > > > just in case they will be useful to someone: > > > > > > - PG_swapcache > > > - PG_swapbacked > > > - PG_mappedtodisk > > > - PG_reserved > > > - PG_private > > > - PG_private_2 > > > - PG_owner_priv_1 > > > > > > - PG_head > > > - PG_tail > > > - PG_compound > > > > > > - PG_unevictable > > > - PG_mlocked > > > > > > - PG_poison > > > > Sorry, NAK this. > > We shouldn't expose internal flags. please choice useful flags only. > > OK. So are there anyone interested in any of these flags? Thanks! > > My rational to export most page flags is that hopefully they could > help debugging kernel at some random situations.. I think, > > > - PG_mappedtodisk > > > - PG_reserved > > > - PG_private > > > - PG_private_2 > > > - PG_owner_priv_1 > > > > > > - PG_head > > > - PG_tail > > > > > > - PG_unevictable > > > - PG_mlocked this 9 flags shouldn't exported. I can't imazine administrator use what purpose those flags. > > > - PG_swapcache > > > - PG_swapbacked > > > - PG_poison > > > - PG_compound I can agree this 4 flags. However pagemap lack's hugepage considering. if PG_compound exporting, we need more work. > > > > Also add the following two pseudo page flags: > > > > > > - PG_MMAP: whether the page is memory mapped hm, I can agree it. > > > - PG_NOPAGE: whether the page is present PM_NOT_PRESENT isn't enough? > > > > > > This increases the total number of exported page flags to 25. > > > > > > Cc: Andi Kleen <andi@firstfloor.org> > > > Cc: Matt Mackall <mpm@selenic.com> > > > Cc: Alexey Dobriyan <adobriyan@gmail.com> > > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > > > --- > > > fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- > > > 1 file changed, 81 insertions(+), 31 deletions(-) > > > > > > --- mm.orig/fs/proc/page.c > > > +++ mm/fs/proc/page.c > > > @@ -68,20 +68,86 @@ static const struct file_operations proc > > > > > > /* These macros are used to decouple internal flags from exported ones */ > > > > > > -#define KPF_LOCKED 0 > > > -#define KPF_ERROR 1 > > > -#define KPF_REFERENCED 2 > > > -#define KPF_UPTODATE 3 > > > -#define KPF_DIRTY 4 > > > -#define KPF_LRU 5 > > > -#define KPF_ACTIVE 6 > > > -#define KPF_SLAB 7 > > > -#define KPF_WRITEBACK 8 > > > -#define KPF_RECLAIM 9 > > > -#define KPF_BUDDY 10 > > > +enum { > > > + KPF_LOCKED, /* 0 */ > > > + KPF_ERROR, /* 1 */ > > > + KPF_REFERENCED, /* 2 */ > > > + KPF_UPTODATE, /* 3 */ > > > + KPF_DIRTY, /* 4 */ > > > + KPF_LRU, /* 5 */ > > > + KPF_ACTIVE, /* 6 */ > > > + KPF_SLAB, /* 7 */ > > > + KPF_WRITEBACK, /* 8 */ > > > + KPF_RECLAIM, /* 9 */ > > > + KPF_BUDDY, /* 10 */ > > > + KPF_MMAP, /* 11 */ > > > + KPF_SWAPCACHE, /* 12 */ > > > + KPF_SWAPBACKED, /* 13 */ > > > + KPF_MAPPEDTODISK, /* 14 */ > > > + KPF_RESERVED, /* 15 */ > > > + KPF_PRIVATE, /* 16 */ > > > + KPF_PRIVATE2, /* 17 */ > > > + KPF_OWNER_PRIVATE, /* 18 */ > > > + KPF_COMPOUND_HEAD, /* 19 */ > > > + KPF_COMPOUND_TAIL, /* 20 */ > > > + KPF_UNEVICTABLE, /* 21 */ > > > + KPF_MLOCKED, /* 22 */ > > > + KPF_POISON, /* 23 */ > > > + KPF_NOPAGE, /* 24 */ > > > + KPF_NUM > > > +}; > > > > this is userland export value. then enum is wrong idea. > > explicit name-number relationship is better. it prevent unintetional > > ABI break. > > Right, that's the reason I add the /* number */ comments. > Anyway, it would be better to use explicit #defines. > > Thanks, > Fengguang > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 6:54 ` KOSAKI Motohiro @ 2009-04-14 7:11 ` Andi Kleen -1 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-14 7:11 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Wu Fengguang, Andrew Morton, Andi Kleen, LKML, linux-mm On Tue, Apr 14, 2009 at 03:54:40PM +0900, KOSAKI Motohiro wrote: > Hi There are two use cases here: First what is useful for the administrator as a general abstraction. And what is useful for the kernel hacker for debugging. The kernel hacker wants everything even if it's subject to change, the administrator wants a higher level abstraction they can make sense of and that doesn't change too often. I think there's a case for both usages, but perhaps they should be separated (in a public and a internal interface perhaps?) My comments below are about abstractions for the first case. > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > Export the following page flags in /proc/kpageflags, > > > > just in case they will be useful to someone: > > > > > > > > - PG_swapcache > > > > - PG_swapbacked > > > > - PG_mappedtodisk > > > > - PG_reserved PG_reserved should be exported as PG_KERNEL or somesuch. > > > > - PG_private > > > > - PG_private_2 > > > > - PG_owner_priv_1 > > > > > > > > - PG_head > > > > - PG_tail > > > > - PG_compound I would combine these three into a pseudo "large page" flag. > > > > > > > > - PG_unevictable > > > > - PG_mlocked > > > > > > > > - PG_poison PG_poison is also useful to export. But since it depends on my patchkit I will pull a patch for that into the HWPOISON series. > > > > - PG_unevictable > > > > - PG_mlocked > > this 9 flags shouldn't exported. > I can't imazine administrator use what purpose those flags. I think an abstraced "PG_pinned" or somesuch flag that combines page lock, unevictable, mlocked would be useful for the administrator. -Andi ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 7:11 ` Andi Kleen 0 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-14 7:11 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Wu Fengguang, Andrew Morton, Andi Kleen, LKML, linux-mm On Tue, Apr 14, 2009 at 03:54:40PM +0900, KOSAKI Motohiro wrote: > Hi There are two use cases here: First what is useful for the administrator as a general abstraction. And what is useful for the kernel hacker for debugging. The kernel hacker wants everything even if it's subject to change, the administrator wants a higher level abstraction they can make sense of and that doesn't change too often. I think there's a case for both usages, but perhaps they should be separated (in a public and a internal interface perhaps?) My comments below are about abstractions for the first case. > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > Export the following page flags in /proc/kpageflags, > > > > just in case they will be useful to someone: > > > > > > > > - PG_swapcache > > > > - PG_swapbacked > > > > - PG_mappedtodisk > > > > - PG_reserved PG_reserved should be exported as PG_KERNEL or somesuch. > > > > - PG_private > > > > - PG_private_2 > > > > - PG_owner_priv_1 > > > > > > > > - PG_head > > > > - PG_tail > > > > - PG_compound I would combine these three into a pseudo "large page" flag. > > > > > > > > - PG_unevictable > > > > - PG_mlocked > > > > > > > > - PG_poison PG_poison is also useful to export. But since it depends on my patchkit I will pull a patch for that into the HWPOISON series. > > > > - PG_unevictable > > > > - PG_mlocked > > this 9 flags shouldn't exported. > I can't imazine administrator use what purpose those flags. I think an abstraced "PG_pinned" or somesuch flag that combines page lock, unevictable, mlocked would be useful for the administrator. -Andi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 7:11 ` Andi Kleen @ 2009-04-14 7:17 ` KOSAKI Motohiro -1 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-14 7:17 UTC (permalink / raw) To: Andi Kleen; +Cc: kosaki.motohiro, Wu Fengguang, Andrew Morton, LKML, linux-mm > On Tue, Apr 14, 2009 at 03:54:40PM +0900, KOSAKI Motohiro wrote: > > Hi > > There are two use cases here: > > First what is useful for the administrator as a general abstraction. > And what is useful for the kernel hacker for debugging. > > The kernel hacker wants everything even if it's subject to change, > the administrator wants a higher level abstraction they can make > sense of and that doesn't change too often. > > I think there's a case for both usages, but perhaps they > should be separated (in a public and a internal interface perhaps?) > > My comments below are about abstractions for the first case. > > > > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > Export the following page flags in /proc/kpageflags, > > > > > just in case they will be useful to someone: > > > > > > > > > > - PG_swapcache > > > > > - PG_swapbacked > > > > > - PG_mappedtodisk > > > > > - PG_reserved > > PG_reserved should be exported as PG_KERNEL or somesuch. OK. rest problem is, how do we write document this. PG_reserved have multiple meanings... > > > > > - PG_private > > > > > - PG_private_2 > > > > > - PG_owner_priv_1 > > > > > > > > > > - PG_head > > > > > - PG_tail > > > > > - PG_compound > > I would combine these three into a pseudo "large page" flag. Ah good idea. > > > > > > > > > > - PG_unevictable > > > > > - PG_mlocked > > > > > > > > > > - PG_poison > > PG_poison is also useful to export. But since it depends on my > patchkit I will pull a patch for that into the HWPOISON series. Yes, I agree. > > > > > - PG_unevictable > > > > > - PG_mlocked > > > > this 9 flags shouldn't exported. > > I can't imazine administrator use what purpose those flags. > > I think an abstraced "PG_pinned" or somesuch flag that combines > page lock, unevictable, mlocked would be useful for the administrator. PG_unevictable and PG_mlocked have a bit delicate meaning. it gurantee the page isn't evicted. but mlock(2) don't gurantee turn page on PG_mlocked. some race prevent it. I'm afraid administrator confuse it. but if someone can write good document, my worriness will vanished. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 7:17 ` KOSAKI Motohiro 0 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-14 7:17 UTC (permalink / raw) To: Andi Kleen; +Cc: kosaki.motohiro, Wu Fengguang, Andrew Morton, LKML, linux-mm > On Tue, Apr 14, 2009 at 03:54:40PM +0900, KOSAKI Motohiro wrote: > > Hi > > There are two use cases here: > > First what is useful for the administrator as a general abstraction. > And what is useful for the kernel hacker for debugging. > > The kernel hacker wants everything even if it's subject to change, > the administrator wants a higher level abstraction they can make > sense of and that doesn't change too often. > > I think there's a case for both usages, but perhaps they > should be separated (in a public and a internal interface perhaps?) > > My comments below are about abstractions for the first case. > > > > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > Export the following page flags in /proc/kpageflags, > > > > > just in case they will be useful to someone: > > > > > > > > > > - PG_swapcache > > > > > - PG_swapbacked > > > > > - PG_mappedtodisk > > > > > - PG_reserved > > PG_reserved should be exported as PG_KERNEL or somesuch. OK. rest problem is, how do we write document this. PG_reserved have multiple meanings... > > > > > - PG_private > > > > > - PG_private_2 > > > > > - PG_owner_priv_1 > > > > > > > > > > - PG_head > > > > > - PG_tail > > > > > - PG_compound > > I would combine these three into a pseudo "large page" flag. Ah good idea. > > > > > > > > > > - PG_unevictable > > > > > - PG_mlocked > > > > > > > > > > - PG_poison > > PG_poison is also useful to export. But since it depends on my > patchkit I will pull a patch for that into the HWPOISON series. Yes, I agree. > > > > > - PG_unevictable > > > > > - PG_mlocked > > > > this 9 flags shouldn't exported. > > I can't imazine administrator use what purpose those flags. > > I think an abstraced "PG_pinned" or somesuch flag that combines > page lock, unevictable, mlocked would be useful for the administrator. PG_unevictable and PG_mlocked have a bit delicate meaning. it gurantee the page isn't evicted. but mlock(2) don't gurantee turn page on PG_mlocked. some race prevent it. I'm afraid administrator confuse it. but if someone can write good document, my worriness will vanished. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 7:11 ` Andi Kleen @ 2009-04-15 13:18 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-15 13:18 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Tue, Apr 14, 2009 at 03:11:59PM +0800, Andi Kleen wrote: > On Tue, Apr 14, 2009 at 03:54:40PM +0900, KOSAKI Motohiro wrote: > > Hi > > There are two use cases here: > > First what is useful for the administrator as a general abstraction. > And what is useful for the kernel hacker for debugging. > > The kernel hacker wants everything even if it's subject to change, > the administrator wants a higher level abstraction they can make > sense of and that doesn't change too often. > > I think there's a case for both usages, but perhaps they > should be separated (in a public and a internal interface perhaps?) That's pretty good separations. I guess it would be convenient to make the extra kernel flags available under CONFIG_DEBUG_KERNEL? > My comments below are about abstractions for the first case. > > > > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > Export the following page flags in /proc/kpageflags, > > > > > just in case they will be useful to someone: > > > > > > > > > > - PG_swapcache > > > > > - PG_swapbacked > > > > > - PG_mappedtodisk > > > > > - PG_reserved > > PG_reserved should be exported as PG_KERNEL or somesuch. PG_KERNEL could be misleading. PG_reserved obviously do not cover all (or most) kernel pages. So I'd prefer to export PG_reserved as it is. It seems that the vast amount of free pages are marked PG_reserved: # uname -a Linux hp 2.6.30-rc2 #157 SMP Wed Apr 15 19:37:49 CST 2009 x86_64 GNU/Linux # echo 1 > /proc/sys/vm/drop_caches # ./page-types flags page-count MB symbolic-flags long-symbolic-flags 0x004000 497474 1943 ______________r_____ reserved 0x008000 4454 17 _______________o____ compound 0x008014 5 0 __R_D__________o____ referenced,dirty,compound 0x000020 1 0 _____l______________ lru 0x000028 310 1 ___U_l______________ uptodate,lru 0x00002c 18 0 __RU_l______________ referenced,uptodate,lru 0x000068 80 0 ___U_lA_____________ uptodate,lru,active 0x00006c 157 0 __RU_lA_____________ referenced,uptodate,lru,active 0x002078 1 0 ___UDlA______b______ uptodate,dirty,lru,active,swapbacked 0x00207c 17 0 __RUDlA______b______ referenced,uptodate,dirty,lru,active,swapbacked 0x000228 13 0 ___U_l___x__________ uptodate,lru,reclaim 0x000400 2085 8 __________B_________ buddy 0x000804 1 0 __R________m________ referenced,mmap 0x002808 10 0 ___U_______m_b______ uptodate,mmap,swapbacked 0x000828 1060 4 ___U_l_____m________ uptodate,lru,mmap 0x00082c 215 0 __RU_l_____m________ referenced,uptodate,lru,mmap 0x000868 189 0 ___U_lA____m________ uptodate,lru,active,mmap 0x002868 4187 16 ___U_lA____m_b______ uptodate,lru,active,mmap,swapbacked 0x00286c 30 0 __RU_lA____m_b______ referenced,uptodate,lru,active,mmap,swapbacked 0x00086c 1012 3 __RU_lA____m________ referenced,uptodate,lru,active,mmap 0x002878 3 0 ___UDlA____m_b______ uptodate,dirty,lru,active,mmap,swapbacked 0x008880 936 3 _______S___m___o____ slab,mmap,compound 0x000880 1602 6 _______S___m________ slab,mmap 0x0088c0 59 0 ______AS___m___o____ active,slab,mmap,compound 0x0008c0 49 0 ______AS___m________ active,slab,mmap total 513968 2007 # ./page-areas 0x004000 offset len KB 0 15 60KB 31 4 16KB 159 97 388KB 4096 2213 8852KB 6899 2385 9540KB 9497 3 12KB 9728 14528 58112KB > > > > > - PG_private > > > > > - PG_private_2 > > > > > - PG_owner_priv_1 > > > > > > > > > > - PG_head > > > > > - PG_tail > > > > > - PG_compound > > I would combine these three into a pseudo "large page" flag. Very neat idea! Patch updated accordingly. However - one pity I observed: # ./page-areas 0x008000 offset len KB 3088 4 16KB We can no longer tell if the above line means one 4-page hugepage, or two 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block can help kernel developers. Or will it be ever cared by administrators? 341196 2 8KB 341202 2 8KB 341262 2 8KB 341272 8 32KB 341296 8 32KB 488448 24 96KB 488490 2 8KB 488496 320 1280KB 488842 2 8KB 488848 40 160KB > > > > > > > > > > - PG_unevictable > > > > > - PG_mlocked > > > > > > > > > > - PG_poison > > PG_poison is also useful to export. But since it depends on my > patchkit I will pull a patch for that into the HWPOISON series. That's not a problem - since the PG_poison line is be protected by #ifdef CONFIG_MEMORY_FAILURE :-) > > > > > - PG_unevictable > > > > > - PG_mlocked > > > > this 9 flags shouldn't exported. > > I can't imazine administrator use what purpose those flags. > > I think an abstraced "PG_pinned" or somesuch flag that combines > page lock, unevictable, mlocked would be useful for the administrator. The PG_PINNED abstraction risks hiding useful information. The administrator may not only care about the pinned pages, but also care _why_ they are pinned, i.e. ramfs.. or mlock? So it might be good to export them as is, with proper document. Here is the v2 patch, with flags for kernel hackers numbered from 32. Comments are welcome! Thanks, Fengguang --- Export all available page flags in /proc/kpageflags, plus two pseudo ones. This increases the total number of exported page flags to 26. TODO: more document Cc: Andi Kleen <andi@firstfloor.org> Cc: Matt Mackall <mpm@selenic.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> --- fs/proc/page.c | 122 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 91 insertions(+), 31 deletions(-) --- mm.orig/fs/proc/page.c +++ mm/fs/proc/page.c @@ -68,20 +68,96 @@ static const struct file_operations proc /* These macros are used to decouple internal flags from exported ones */ -#define KPF_LOCKED 0 -#define KPF_ERROR 1 -#define KPF_REFERENCED 2 -#define KPF_UPTODATE 3 -#define KPF_DIRTY 4 -#define KPF_LRU 5 -#define KPF_ACTIVE 6 -#define KPF_SLAB 7 -#define KPF_WRITEBACK 8 -#define KPF_RECLAIM 9 -#define KPF_BUDDY 10 +#define KPF_LOCKED 0 +#define KPF_ERROR 1 +#define KPF_REFERENCED 2 +#define KPF_UPTODATE 3 +#define KPF_DIRTY 4 +#define KPF_LRU 5 +#define KPF_ACTIVE 6 +#define KPF_SLAB 7 +#define KPF_WRITEBACK 8 +#define KPF_RECLAIM 9 +#define KPF_BUDDY 10 + +/* new additions in 2.6.31 */ +#define KPF_MMAP 11 +#define KPF_SWAPCACHE 12 +#define KPF_SWAPBACKED 13 +#define KPF_RESERVED 14 +#define KPF_COMPOUND 15 +#define KPF_UNEVICTABLE 16 +#define KPF_MLOCKED 17 +#define KPF_POISON 18 +#define KPF_NOPAGE 19 + +/* kernel hacking assistances */ +#define KPF_MAPPEDTODISK 32 +#define KPF_PRIVATE 33 +#define KPF_PRIVATE2 34 +#define KPF_OWNER_PRIVATE 35 +#define KPF_ARCH 36 +#define KPF_UNCACHED 37 #define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) +u64 get_uflags(struct page *page) +{ + u64 kflags; + u64 uflags; + + if (!page) + return 1 << KPF_NOPAGE; + + kflags = page->flags; + uflags = 0; + + if (page_mapped(page)) + uflags |= 1 << KPF_MMAP; + + uflags |= kpf_copy_bit(kflags, KPF_LOCKED, PG_locked); + uflags |= kpf_copy_bit(kflags, KPF_ERROR, PG_error); + uflags |= kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced); + uflags |= kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate); + uflags |= kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty); + uflags |= kpf_copy_bit(kflags, KPF_LRU, PG_lru) ; + uflags |= kpf_copy_bit(kflags, KPF_ACTIVE, PG_active); + uflags |= kpf_copy_bit(kflags, KPF_SLAB, PG_slab); + uflags |= kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback); + uflags |= kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim); + uflags |= kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); + + uflags |= kpf_copy_bit(kflags, KPF_SWAPCACHE, PG_swapcache); + uflags |= kpf_copy_bit(kflags, KPF_SWAPBACKED, PG_swapbacked); + uflags |= kpf_copy_bit(kflags, KPF_RESERVED, PG_reserved); +#ifdef CONFIG_PAGEFLAGS_EXTENDED + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_head); + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_tail); +#else + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_compound); +#endif +#ifdef CONFIG_UNEVICTABLE_LRU + uflags |= kpf_copy_bit(kflags, KPF_UNEVICTABLE, PG_unevictable); + uflags |= kpf_copy_bit(kflags, KPF_MLOCKED, PG_mlocked); +#endif +#ifdef CONFIG_MEMORY_FAILURE + uflags |= kpf_copy_bit(kflags, KPF_POISON, PG_poison); +#endif + +#ifdef CONFIG_DEBUG_KERNEL + uflags |= kpf_copy_bit(kflags, KPF_MAPPEDTODISK, PG_mappedtodisk); + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE, PG_private); + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE2, PG_private_2); + uflags |= kpf_copy_bit(kflags, KPF_OWNER_PRIVATE, PG_owner_priv_1); + uflags |= kpf_copy_bit(kflags, KPF_ARCH, PG_arch_1); +#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR + uflags |= kpf_copy_bit(kflags, KPF_UNCACHED, PG_uncached); +#endif +#endif + + return uflags; +}; + static ssize_t kpageflags_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { @@ -90,7 +166,6 @@ static ssize_t kpageflags_read(struct fi unsigned long src = *ppos; unsigned long pfn; ssize_t ret = 0; - u64 kflags, uflags; pfn = src / KPMSIZE; count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); @@ -98,32 +173,17 @@ static ssize_t kpageflags_read(struct fi return -EINVAL; while (count > 0) { - ppage = NULL; if (pfn_valid(pfn)) ppage = pfn_to_page(pfn); - pfn++; - if (!ppage) - kflags = 0; else - kflags = ppage->flags; - - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); + ppage = NULL; - if (put_user(uflags, out++)) { + if (put_user(get_uflags(ppage), out)) { ret = -EFAULT; break; } - + out++; + pfn++; count -= KPMSIZE; } ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-15 13:18 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-15 13:18 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Tue, Apr 14, 2009 at 03:11:59PM +0800, Andi Kleen wrote: > On Tue, Apr 14, 2009 at 03:54:40PM +0900, KOSAKI Motohiro wrote: > > Hi > > There are two use cases here: > > First what is useful for the administrator as a general abstraction. > And what is useful for the kernel hacker for debugging. > > The kernel hacker wants everything even if it's subject to change, > the administrator wants a higher level abstraction they can make > sense of and that doesn't change too often. > > I think there's a case for both usages, but perhaps they > should be separated (in a public and a internal interface perhaps?) That's pretty good separations. I guess it would be convenient to make the extra kernel flags available under CONFIG_DEBUG_KERNEL? > My comments below are about abstractions for the first case. > > > > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > Export the following page flags in /proc/kpageflags, > > > > > just in case they will be useful to someone: > > > > > > > > > > - PG_swapcache > > > > > - PG_swapbacked > > > > > - PG_mappedtodisk > > > > > - PG_reserved > > PG_reserved should be exported as PG_KERNEL or somesuch. PG_KERNEL could be misleading. PG_reserved obviously do not cover all (or most) kernel pages. So I'd prefer to export PG_reserved as it is. It seems that the vast amount of free pages are marked PG_reserved: # uname -a Linux hp 2.6.30-rc2 #157 SMP Wed Apr 15 19:37:49 CST 2009 x86_64 GNU/Linux # echo 1 > /proc/sys/vm/drop_caches # ./page-types flags page-count MB symbolic-flags long-symbolic-flags 0x004000 497474 1943 ______________r_____ reserved 0x008000 4454 17 _______________o____ compound 0x008014 5 0 __R_D__________o____ referenced,dirty,compound 0x000020 1 0 _____l______________ lru 0x000028 310 1 ___U_l______________ uptodate,lru 0x00002c 18 0 __RU_l______________ referenced,uptodate,lru 0x000068 80 0 ___U_lA_____________ uptodate,lru,active 0x00006c 157 0 __RU_lA_____________ referenced,uptodate,lru,active 0x002078 1 0 ___UDlA______b______ uptodate,dirty,lru,active,swapbacked 0x00207c 17 0 __RUDlA______b______ referenced,uptodate,dirty,lru,active,swapbacked 0x000228 13 0 ___U_l___x__________ uptodate,lru,reclaim 0x000400 2085 8 __________B_________ buddy 0x000804 1 0 __R________m________ referenced,mmap 0x002808 10 0 ___U_______m_b______ uptodate,mmap,swapbacked 0x000828 1060 4 ___U_l_____m________ uptodate,lru,mmap 0x00082c 215 0 __RU_l_____m________ referenced,uptodate,lru,mmap 0x000868 189 0 ___U_lA____m________ uptodate,lru,active,mmap 0x002868 4187 16 ___U_lA____m_b______ uptodate,lru,active,mmap,swapbacked 0x00286c 30 0 __RU_lA____m_b______ referenced,uptodate,lru,active,mmap,swapbacked 0x00086c 1012 3 __RU_lA____m________ referenced,uptodate,lru,active,mmap 0x002878 3 0 ___UDlA____m_b______ uptodate,dirty,lru,active,mmap,swapbacked 0x008880 936 3 _______S___m___o____ slab,mmap,compound 0x000880 1602 6 _______S___m________ slab,mmap 0x0088c0 59 0 ______AS___m___o____ active,slab,mmap,compound 0x0008c0 49 0 ______AS___m________ active,slab,mmap total 513968 2007 # ./page-areas 0x004000 offset len KB 0 15 60KB 31 4 16KB 159 97 388KB 4096 2213 8852KB 6899 2385 9540KB 9497 3 12KB 9728 14528 58112KB > > > > > - PG_private > > > > > - PG_private_2 > > > > > - PG_owner_priv_1 > > > > > > > > > > - PG_head > > > > > - PG_tail > > > > > - PG_compound > > I would combine these three into a pseudo "large page" flag. Very neat idea! Patch updated accordingly. However - one pity I observed: # ./page-areas 0x008000 offset len KB 3088 4 16KB We can no longer tell if the above line means one 4-page hugepage, or two 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block can help kernel developers. Or will it be ever cared by administrators? 341196 2 8KB 341202 2 8KB 341262 2 8KB 341272 8 32KB 341296 8 32KB 488448 24 96KB 488490 2 8KB 488496 320 1280KB 488842 2 8KB 488848 40 160KB > > > > > > > > > > - PG_unevictable > > > > > - PG_mlocked > > > > > > > > > > - PG_poison > > PG_poison is also useful to export. But since it depends on my > patchkit I will pull a patch for that into the HWPOISON series. That's not a problem - since the PG_poison line is be protected by #ifdef CONFIG_MEMORY_FAILURE :-) > > > > > - PG_unevictable > > > > > - PG_mlocked > > > > this 9 flags shouldn't exported. > > I can't imazine administrator use what purpose those flags. > > I think an abstraced "PG_pinned" or somesuch flag that combines > page lock, unevictable, mlocked would be useful for the administrator. The PG_PINNED abstraction risks hiding useful information. The administrator may not only care about the pinned pages, but also care _why_ they are pinned, i.e. ramfs.. or mlock? So it might be good to export them as is, with proper document. Here is the v2 patch, with flags for kernel hackers numbered from 32. Comments are welcome! Thanks, Fengguang --- Export all available page flags in /proc/kpageflags, plus two pseudo ones. This increases the total number of exported page flags to 26. TODO: more document Cc: Andi Kleen <andi@firstfloor.org> Cc: Matt Mackall <mpm@selenic.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> --- fs/proc/page.c | 122 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 91 insertions(+), 31 deletions(-) --- mm.orig/fs/proc/page.c +++ mm/fs/proc/page.c @@ -68,20 +68,96 @@ static const struct file_operations proc /* These macros are used to decouple internal flags from exported ones */ -#define KPF_LOCKED 0 -#define KPF_ERROR 1 -#define KPF_REFERENCED 2 -#define KPF_UPTODATE 3 -#define KPF_DIRTY 4 -#define KPF_LRU 5 -#define KPF_ACTIVE 6 -#define KPF_SLAB 7 -#define KPF_WRITEBACK 8 -#define KPF_RECLAIM 9 -#define KPF_BUDDY 10 +#define KPF_LOCKED 0 +#define KPF_ERROR 1 +#define KPF_REFERENCED 2 +#define KPF_UPTODATE 3 +#define KPF_DIRTY 4 +#define KPF_LRU 5 +#define KPF_ACTIVE 6 +#define KPF_SLAB 7 +#define KPF_WRITEBACK 8 +#define KPF_RECLAIM 9 +#define KPF_BUDDY 10 + +/* new additions in 2.6.31 */ +#define KPF_MMAP 11 +#define KPF_SWAPCACHE 12 +#define KPF_SWAPBACKED 13 +#define KPF_RESERVED 14 +#define KPF_COMPOUND 15 +#define KPF_UNEVICTABLE 16 +#define KPF_MLOCKED 17 +#define KPF_POISON 18 +#define KPF_NOPAGE 19 + +/* kernel hacking assistances */ +#define KPF_MAPPEDTODISK 32 +#define KPF_PRIVATE 33 +#define KPF_PRIVATE2 34 +#define KPF_OWNER_PRIVATE 35 +#define KPF_ARCH 36 +#define KPF_UNCACHED 37 #define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) +u64 get_uflags(struct page *page) +{ + u64 kflags; + u64 uflags; + + if (!page) + return 1 << KPF_NOPAGE; + + kflags = page->flags; + uflags = 0; + + if (page_mapped(page)) + uflags |= 1 << KPF_MMAP; + + uflags |= kpf_copy_bit(kflags, KPF_LOCKED, PG_locked); + uflags |= kpf_copy_bit(kflags, KPF_ERROR, PG_error); + uflags |= kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced); + uflags |= kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate); + uflags |= kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty); + uflags |= kpf_copy_bit(kflags, KPF_LRU, PG_lru) ; + uflags |= kpf_copy_bit(kflags, KPF_ACTIVE, PG_active); + uflags |= kpf_copy_bit(kflags, KPF_SLAB, PG_slab); + uflags |= kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback); + uflags |= kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim); + uflags |= kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); + + uflags |= kpf_copy_bit(kflags, KPF_SWAPCACHE, PG_swapcache); + uflags |= kpf_copy_bit(kflags, KPF_SWAPBACKED, PG_swapbacked); + uflags |= kpf_copy_bit(kflags, KPF_RESERVED, PG_reserved); +#ifdef CONFIG_PAGEFLAGS_EXTENDED + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_head); + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_tail); +#else + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_compound); +#endif +#ifdef CONFIG_UNEVICTABLE_LRU + uflags |= kpf_copy_bit(kflags, KPF_UNEVICTABLE, PG_unevictable); + uflags |= kpf_copy_bit(kflags, KPF_MLOCKED, PG_mlocked); +#endif +#ifdef CONFIG_MEMORY_FAILURE + uflags |= kpf_copy_bit(kflags, KPF_POISON, PG_poison); +#endif + +#ifdef CONFIG_DEBUG_KERNEL + uflags |= kpf_copy_bit(kflags, KPF_MAPPEDTODISK, PG_mappedtodisk); + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE, PG_private); + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE2, PG_private_2); + uflags |= kpf_copy_bit(kflags, KPF_OWNER_PRIVATE, PG_owner_priv_1); + uflags |= kpf_copy_bit(kflags, KPF_ARCH, PG_arch_1); +#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR + uflags |= kpf_copy_bit(kflags, KPF_UNCACHED, PG_uncached); +#endif +#endif + + return uflags; +}; + static ssize_t kpageflags_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { @@ -90,7 +166,6 @@ static ssize_t kpageflags_read(struct fi unsigned long src = *ppos; unsigned long pfn; ssize_t ret = 0; - u64 kflags, uflags; pfn = src / KPMSIZE; count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); @@ -98,32 +173,17 @@ static ssize_t kpageflags_read(struct fi return -EINVAL; while (count > 0) { - ppage = NULL; if (pfn_valid(pfn)) ppage = pfn_to_page(pfn); - pfn++; - if (!ppage) - kflags = 0; else - kflags = ppage->flags; - - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); + ppage = NULL; - if (put_user(uflags, out++)) { + if (put_user(get_uflags(ppage), out)) { ret = -EFAULT; break; } - + out++; + pfn++; count -= KPMSIZE; } -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-15 13:18 ` Wu Fengguang @ 2009-04-15 13:57 ` Andi Kleen -1 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-15 13:57 UTC (permalink / raw) To: Wu Fengguang; +Cc: Andi Kleen, KOSAKI Motohiro, Andrew Morton, LKML, linux-mm > That's pretty good separations. I guess it would be convenient to make the > extra kernel flags available under CONFIG_DEBUG_KERNEL? Yes. BTW an alternative would be just someone implementing a suitable command/macro in crash(1) and tell the kernel hackers to run that on /proc/kcore. That would have the advantage to not require code. > > > > > > - PG_compound > > > > I would combine these three into a pseudo "large page" flag. > > Very neat idea! Patch updated accordingly. > > However - one pity I observed: > > # ./page-areas 0x008000 > offset len KB > 3088 4 16KB > > We can no longer tell if the above line means one 4-page hugepage, or two > 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block There's only a single size (2 or 4MB), at worst two. > > > > PG_poison is also useful to export. But since it depends on my > > patchkit I will pull a patch for that into the HWPOISON series. > > That's not a problem - since the PG_poison line is be protected by > #ifdef CONFIG_MEMORY_FAILURE :-) Good point. I added a patch to only add it to my pile, but I can drop that again. -Andi ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-15 13:57 ` Andi Kleen 0 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-15 13:57 UTC (permalink / raw) To: Wu Fengguang; +Cc: Andi Kleen, KOSAKI Motohiro, Andrew Morton, LKML, linux-mm > That's pretty good separations. I guess it would be convenient to make the > extra kernel flags available under CONFIG_DEBUG_KERNEL? Yes. BTW an alternative would be just someone implementing a suitable command/macro in crash(1) and tell the kernel hackers to run that on /proc/kcore. That would have the advantage to not require code. > > > > > > - PG_compound > > > > I would combine these three into a pseudo "large page" flag. > > Very neat idea! Patch updated accordingly. > > However - one pity I observed: > > # ./page-areas 0x008000 > offset len KB > 3088 4 16KB > > We can no longer tell if the above line means one 4-page hugepage, or two > 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block There's only a single size (2 or 4MB), at worst two. > > > > PG_poison is also useful to export. But since it depends on my > > patchkit I will pull a patch for that into the HWPOISON series. > > That's not a problem - since the PG_poison line is be protected by > #ifdef CONFIG_MEMORY_FAILURE :-) Good point. I added a patch to only add it to my pile, but I can drop that again. -Andi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-15 13:57 ` Andi Kleen @ 2009-04-16 2:41 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-16 2:41 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Wed, Apr 15, 2009 at 09:57:49PM +0800, Andi Kleen wrote: > > That's pretty good separations. I guess it would be convenient to make the > > extra kernel flags available under CONFIG_DEBUG_KERNEL? > > Yes. > > BTW an alternative would be just someone implementing a suitable > command/macro in crash(1) and tell the kernel hackers to run that on > /proc/kcore. That would have the advantage to not require code. Hmm, that would be horrible to code/maintain. One major purpose of /proc/kpageflags is to export the unstable kernel page flag bits as stable ones to user space. Note that the exact internal flag bits can not only change slowly with kernel versions, but more likely with different kconfig combinations. > > > > > > > - PG_compound > > > > > > I would combine these three into a pseudo "large page" flag. > > > > Very neat idea! Patch updated accordingly. > > > > However - one pity I observed: > > > > # ./page-areas 0x008000 > > offset len KB > > 3088 4 16KB > > > > We can no longer tell if the above line means one 4-page hugepage, or two > > 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block > > There's only a single size (2 or 4MB), at worst two. Sorry I was not only referring to the CPU huge pages, but also the more general compound pages retrieved with __GFP_COMP, by SLUB and many drivers, in various orders. After adding PG_COMPOUND_TAIL: # ./page-types flags page-count MB symbolic-flags long-symbolic-flags 0x000000004000 491394 1919 ______________r____________ reserved 0x000000008000 15 0 _______________o___________ compound 0x004000008000 4293 16 _______________o__________T compound,compound_tail 0x000000008014 1 0 __R_D__________o___________ referenced,dirty,compound 0x004000008014 4 0 __R_D__________o__________T referenced,dirty,compound,compound_tail 0x000000000020 1 0 _____l_____________________ lru 0x000000000028 2630 10 ___U_l_____________________ uptodate,lru 0x00000000002c 5244 20 __RU_l_____________________ referenced,uptodate,lru 0x000000000068 240 0 ___U_lA____________________ uptodate,lru,active 0x00000000006c 924 3 __RU_lA____________________ referenced,uptodate,lru,active 0x000000002078 1 0 ___UDlA______b_____________ uptodate,dirty,lru,active,swapbacked 0x00000000207c 17 0 __RUDlA______b_____________ referenced,uptodate,dirty,lru,active,swapbacked 0x000000000228 49 0 ___U_l___x_________________ uptodate,lru,reclaim 0x000000000400 528 2 __________B________________ buddy 0x000000000804 1 0 __R________m_______________ referenced,mmap 0x000000002808 10 0 ___U_______m_b_____________ uptodate,mmap,swapbacked 0x000000000828 1140 4 ___U_l_____m_______________ uptodate,lru,mmap 0x00000000082c 280 1 __RU_l_____m_______________ referenced,uptodate,lru,mmap 0x000000002868 3658 14 ___U_lA____m_b_____________ uptodate,lru,active,mmap,swapbacked 0x000000000868 367 1 ___U_lA____m_______________ uptodate,lru,active,mmap 0x00000000086c 622 2 __RU_lA____m_______________ referenced,uptodate,lru,active,mmap 0x00000000286c 28 0 __RU_lA____m_b_____________ referenced,uptodate,lru,active,mmap,swapbacked 0x000000002878 2 0 ___UDlA____m_b_____________ uptodate,dirty,lru,active,mmap,swapbacked 0x000000000880 1497 5 _______S___m_______________ slab,mmap 0x000000008880 914 3 _______S___m___o___________ slab,mmap,compound 0x0000000008c0 49 0 ______AS___m_______________ active,slab,mmap 0x0000000088c0 59 0 ______AS___m___o___________ active,slab,mmap,compound total 513968 2007 It's interesting that the compound heads and compound tails don't match (even closely). There are 16 compound head pages, but 989 segments of compound tails: root@hp /home/wfg# ./page-areas =0x000000008000|wc -l 16 root@hp /home/wfg# ./page-areas =0x004000008000|wc -l 989 Followed are their detailed locations. Did we found a bug? ;-) Thanks, Fengguang --- root@hp /home/wfg# ./page-areas =0x000000008000 offset len KB 3088 1 4KB 497664 1 4KB 500128 1 4KB 502952 1 4KB 503056 1 4KB 503264 1 4KB 504860 1 4KB 504960 1 4KB 504964 1 4KB 506204 1 4KB 506272 1 4KB 506304 1 4KB 509088 1 4KB 509964 1 4KB 512988 1 4KB root@hp /home/wfg# ./page-areas =0x004000008000 offset len KB 3089 3 12KB 487437 3 12KB 487441 3 12KB 487445 3 12KB 487449 3 12KB 487453 3 12KB 487457 3 12KB 487491 1 4KB 487497 7 28KB 487505 7 28KB 487513 7 28KB 487521 7 28KB 487529 7 28KB 487537 7 28KB 487545 7 28KB 487577 1 4KB 490497 3 12KB 490509 3 12KB 490521 7 28KB 490529 3 12KB 490533 3 12KB 490537 3 12KB 490541 3 12KB 490545 3 12KB 490549 3 12KB 490557 3 12KB 490565 3 12KB 490569 3 12KB 490573 3 12KB 490577 3 12KB 490581 3 12KB 490585 3 12KB 490593 3 12KB 490597 3 12KB 490601 3 12KB 490605 3 12KB 490609 3 12KB 490613 3 12KB 490617 3 12KB 490633 3 12KB 490637 3 12KB 490641 3 12KB 490645 3 12KB 490649 3 12KB 490653 3 12KB 490665 7 28KB 490673 7 28KB 490713 1 4KB 490715 1 4KB 490717 3 12KB 490721 7 28KB 490729 7 28KB 490737 1 4KB 490739 1 4KB 490741 3 12KB 490745 7 28KB 490753 3 12KB 490757 3 12KB 490761 7 28KB 490769 7 28KB 490777 7 28KB 490785 7 28KB 490793 7 28KB 490801 3 12KB 490823 1 4KB 490825 7 28KB 490833 7 28KB 490841 3 12KB 490845 1 4KB 490847 1 4KB 490849 7 28KB 490857 7 28KB 490865 1 4KB 490873 7 28KB 490881 7 28KB 490889 7 28KB 490897 7 28KB 490905 7 28KB 490913 7 28KB 490921 7 28KB 490929 7 28KB 490937 7 28KB 490945 7 28KB 490953 7 28KB 490961 7 28KB 490969 7 28KB 490977 7 28KB 490985 7 28KB 490993 7 28KB 491001 7 28KB 491009 7 28KB 491033 7 28KB 491067 1 4KB 491069 1 4KB 491073 7 28KB 491081 7 28KB 491089 7 28KB 491097 7 28KB 491105 7 28KB 491113 7 28KB 491121 7 28KB 491129 7 28KB 491137 7 28KB 491145 7 28KB 491153 7 28KB 491161 7 28KB 491169 7 28KB 491177 7 28KB 491185 7 28KB 491193 7 28KB 491201 7 28KB 491209 7 28KB 491217 7 28KB 491225 7 28KB 491233 7 28KB 491241 7 28KB 491249 7 28KB 491257 7 28KB 491265 7 28KB 491273 7 28KB 491281 7 28KB 491289 7 28KB 491297 7 28KB 491305 7 28KB 491313 7 28KB 491321 7 28KB 491329 7 28KB 491337 7 28KB 491345 7 28KB 491353 7 28KB 491361 7 28KB 491369 7 28KB 491377 7 28KB 491385 7 28KB 491393 7 28KB 491401 7 28KB 491409 7 28KB 491417 7 28KB 491457 7 28KB 491465 7 28KB 496657 7 28KB 496677 3 12KB 496681 7 28KB 496689 7 28KB 496713 7 28KB 496721 7 28KB 496735 1 4KB 497665 31 124KB 497697 7 28KB 497705 7 28KB 497775 1 4KB 497777 7 28KB 497853 3 12KB 497865 7 28KB 498761 3 12KB 498765 3 12KB 498777 1 4KB 498817 7 28KB 498825 7 28KB 498865 1 4KB 498877 3 12KB 498881 1 4KB 498883 1 4KB 498889 7 28KB 498901 3 12KB 498911 1 4KB 498913 7 28KB 498925 3 12KB 498929 7 28KB 498937 7 28KB 498945 3 12KB 498949 3 12KB 498953 3 12KB 498957 3 12KB 498969 7 28KB 498981 3 12KB 498985 3 12KB 499001 7 28KB 499009 7 28KB 499021 1 4KB 499025 7 28KB 499033 7 28KB 499041 7 28KB 499049 7 28KB 499057 7 28KB 499065 7 28KB 499079 1 4KB 499081 3 12KB 499085 3 12KB 499091 1 4KB 499105 7 28KB 499113 7 28KB 499121 7 28KB 499129 7 28KB 499137 3 12KB 499141 1 4KB 499143 1 4KB 499145 7 28KB 499163 1 4KB 499165 3 12KB 499169 3 12KB 499175 1 4KB 499177 7 28KB 499185 3 12KB 499189 3 12KB 499193 7 28KB 499201 7 28KB 499209 7 28KB 499217 7 28KB 499225 3 12KB 499229 3 12KB 499233 7 28KB 499241 3 12KB 499249 3 12KB 499253 3 12KB 499257 3 12KB 499261 3 12KB 499265 3 12KB 499269 3 12KB 499273 3 12KB 499277 3 12KB 499281 3 12KB 499285 3 12KB 499289 3 12KB 499293 3 12KB 499297 3 12KB 499301 3 12KB 499305 3 12KB 499309 3 12KB 499313 3 12KB 499317 3 12KB 499321 3 12KB 499325 3 12KB 499329 3 12KB 499333 3 12KB 499337 3 12KB 499341 3 12KB 499345 3 12KB 499349 3 12KB 499353 3 12KB 499357 3 12KB 499361 3 12KB 499365 3 12KB 499369 3 12KB 499373 3 12KB 499377 3 12KB 499381 3 12KB 499385 3 12KB 499419 1 4KB 499421 3 12KB 499425 3 12KB 499429 3 12KB 499433 3 12KB 499437 3 12KB 499441 3 12KB 499445 3 12KB 499481 3 12KB 499485 3 12KB 499489 3 12KB 499493 3 12KB 499497 3 12KB 499501 3 12KB 499505 3 12KB 499509 3 12KB 499513 1 4KB 499517 3 12KB 499521 3 12KB 499557 3 12KB 499561 3 12KB 499565 3 12KB 499569 3 12KB 499573 3 12KB 499577 3 12KB 499581 3 12KB 499585 3 12KB 499589 3 12KB 499593 3 12KB 499629 3 12KB 499633 3 12KB 499637 3 12KB 499641 3 12KB 499645 3 12KB 499649 3 12KB 499653 3 12KB 499689 3 12KB 499693 3 12KB 499697 3 12KB 499701 3 12KB 499705 3 12KB 499709 3 12KB 499713 7 28KB 499721 7 28KB 499729 7 28KB 499737 7 28KB 499745 7 28KB 499753 7 28KB 499761 7 28KB 499769 7 28KB 499777 7 28KB 499785 7 28KB 499793 7 28KB 499801 7 28KB 499825 7 28KB 499833 7 28KB 499841 7 28KB 499849 7 28KB 499865 7 28KB 499873 7 28KB 499881 7 28KB 499889 7 28KB 499897 7 28KB 499913 7 28KB 499929 7 28KB 499937 7 28KB 499953 7 28KB 499961 7 28KB 499969 7 28KB 499977 7 28KB 499993 7 28KB 500001 7 28KB 500009 7 28KB 500025 7 28KB 500033 7 28KB 500041 7 28KB 500049 7 28KB 500057 7 28KB 500069 11 44KB 500081 7 28KB 500089 7 28KB 500105 7 28KB 500113 7 28KB 500121 7 28KB 500129 15 60KB 500145 7 28KB 500153 7 28KB 500161 7 28KB 500185 7 28KB 500193 7 28KB 500209 7 28KB 500217 7 28KB 500233 7 28KB 500289 7 28KB 500297 7 28KB 500305 7 28KB 500313 7 28KB 500321 7 28KB 500329 7 28KB 500337 7 28KB 500345 7 28KB 500353 7 28KB 500361 7 28KB 500369 7 28KB 500377 7 28KB 500385 7 28KB 500393 7 28KB 500401 7 28KB 500409 7 28KB 500417 7 28KB 500425 7 28KB 500433 7 28KB 500441 7 28KB 500743 1 4KB 500745 7 28KB 500753 7 28KB 500769 7 28KB 500795 1 4KB 500817 7 28KB 500841 7 28KB 500849 7 28KB 500857 7 28KB 500873 7 28KB 500881 7 28KB 500889 7 28KB 500911 1 4KB 500921 7 28KB 500937 7 28KB 500961 7 28KB 500977 7 28KB 500985 7 28KB 501001 7 28KB 501017 7 28KB 501025 7 28KB 501057 7 28KB 501071 1 4KB 501081 7 28KB 501129 7 28KB 501145 7 28KB 501153 7 28KB 501169 7 28KB 501177 7 28KB 501185 7 28KB 501225 7 28KB 501241 7 28KB 501305 1 4KB 501309 3 12KB 501313 1 4KB 501761 3 12KB 501765 3 12KB 501769 3 12KB 501773 3 12KB 501777 3 12KB 501781 3 12KB 501785 3 12KB 501789 3 12KB 501793 3 12KB 501797 3 12KB 501801 3 12KB 501805 3 12KB 501809 3 12KB 501813 3 12KB 501817 3 12KB 501821 3 12KB 501825 3 12KB 501829 3 12KB 501833 3 12KB 501837 3 12KB 501841 3 12KB 501845 3 12KB 501849 3 12KB 501853 3 12KB 501857 3 12KB 501861 3 12KB 501865 3 12KB 501869 3 12KB 501873 3 12KB 501877 3 12KB 501881 3 12KB 501885 3 12KB 501917 3 12KB 501921 3 12KB 501925 3 12KB 501929 3 12KB 501933 3 12KB 501937 3 12KB 501941 3 12KB 501945 3 12KB 501949 3 12KB 501953 3 12KB 501957 3 12KB 501961 3 12KB 501965 3 12KB 501969 3 12KB 501973 3 12KB 501977 3 12KB 501981 3 12KB 501985 3 12KB 501989 3 12KB 501993 3 12KB 501997 3 12KB 502001 3 12KB 502005 3 12KB 502009 3 12KB 502013 3 12KB 502017 3 12KB 502021 3 12KB 502025 3 12KB 502029 3 12KB 502033 3 12KB 502037 3 12KB 502041 3 12KB 502045 3 12KB 502049 3 12KB 502053 3 12KB 502077 3 12KB 502081 3 12KB 502085 3 12KB 502089 3 12KB 502093 3 12KB 502097 3 12KB 502101 3 12KB 502105 3 12KB 502109 3 12KB 502113 3 12KB 502117 3 12KB 502121 3 12KB 502125 3 12KB 502129 3 12KB 502133 3 12KB 502137 3 12KB 502141 3 12KB 502145 3 12KB 502149 3 12KB 502153 3 12KB 502157 3 12KB 502161 3 12KB 502165 3 12KB 502169 3 12KB 502173 3 12KB 502177 3 12KB 502181 3 12KB 502185 3 12KB 502201 3 12KB 502205 3 12KB 502219 1 4KB 502229 3 12KB 502233 3 12KB 502237 1 4KB 502241 3 12KB 502245 3 12KB 502253 3 12KB 502265 3 12KB 502289 3 12KB 502293 3 12KB 502297 3 12KB 502301 3 12KB 502305 3 12KB 502309 3 12KB 502313 3 12KB 502317 3 12KB 502321 3 12KB 502329 3 12KB 502369 3 12KB 502373 3 12KB 502377 3 12KB 502385 7 28KB 502405 3 12KB 502409 3 12KB 502445 3 12KB 502529 1 4KB 502531 1 4KB 502533 3 12KB 502595 1 4KB 502597 3 12KB 502833 7 28KB 502841 7 28KB 502849 7 28KB 502857 7 28KB 502869 1 4KB 502873 7 28KB 502913 7 28KB 502921 7 28KB 502945 7 28KB 502953 3 12KB 502963 1 4KB 502993 7 28KB 503041 7 28KB 503049 7 28KB 503057 7 28KB 503069 3 12KB 503073 7 28KB 503087 1 4KB 503089 7 28KB 503101 3 12KB 503105 7 28KB 503113 1 4KB 503137 7 28KB 503149 1 4KB 503155 1 4KB 503157 3 12KB 503161 7 28KB 503173 1 4KB 503177 7 28KB 503185 7 28KB 503195 1 4KB 503225 7 28KB 503249 7 28KB 503265 3 12KB 503273 7 28KB 503281 3 12KB 503287 1 4KB 503289 7 28KB 503813 3 12KB 503821 3 12KB 503825 7 28KB 503833 1 4KB 503837 1 4KB 503869 3 12KB 503897 7 28KB 503905 7 28KB 503925 3 12KB 503929 7 28KB 503937 7 28KB 503953 7 28KB 503985 7 28KB 503993 7 28KB 504001 7 28KB 504009 3 12KB 504029 3 12KB 504033 7 28KB 504041 7 28KB 504049 7 28KB 504057 7 28KB 504065 7 28KB 504073 7 28KB 504081 7 28KB 504089 7 28KB 504097 7 28KB 504105 7 28KB 504113 1 4KB 504115 1 4KB 504121 7 28KB 504161 7 28KB 504169 7 28KB 504187 1 4KB 504193 7 28KB 504201 7 28KB 504209 7 28KB 504217 7 28KB 504225 7 28KB 504233 7 28KB 504241 7 28KB 504257 7 28KB 504265 7 28KB 504281 1 4KB 504295 1 4KB 504297 7 28KB 504309 3 12KB 504313 7 28KB 504833 7 28KB 504851 1 4KB 504861 3 12KB 504873 7 28KB 504881 1 4KB 504883 1 4KB 504889 7 28KB 504897 7 28KB 504909 3 12KB 504913 3 12KB 504917 1 4KB 504919 1 4KB 504921 1 4KB 504953 7 28KB 504961 3 12KB 504965 3 12KB 504977 7 28KB 504985 7 28KB 504993 7 28KB 505025 7 28KB 505033 7 28KB 505041 7 28KB 505065 3 12KB 505073 3 12KB 505081 7 28KB 505089 7 28KB 505137 7 28KB 505153 7 28KB 505169 7 28KB 505177 7 28KB 505185 7 28KB 505209 7 28KB 505217 7 28KB 505225 7 28KB 505233 7 28KB 505241 7 28KB 505249 7 28KB 505293 3 12KB 505297 7 28KB 505309 3 12KB 505313 7 28KB 505321 7 28KB 505337 1 4KB 505341 1 4KB 505343 1 4KB 505875 1 4KB 505877 1 4KB 505879 1 4KB 505885 3 12KB 505889 7 28KB 505899 1 4KB 505901 1 4KB 505905 7 28KB 505919 1 4KB 505921 7 28KB 505929 1 4KB 505933 3 12KB 505937 7 28KB 505947 1 4KB 505953 7 28KB 505969 7 28KB 505977 7 28KB 505985 1 4KB 505987 1 4KB 505989 1 4KB 505991 1 4KB 505993 1 4KB 505995 1 4KB 506005 1 4KB 506039 1 4KB 506041 7 28KB 506053 1 4KB 506055 1 4KB 506073 7 28KB 506089 1 4KB 506091 1 4KB 506093 1 4KB 506095 1 4KB 506101 1 4KB 506109 1 4KB 506111 1 4KB 506159 1 4KB 506169 1 4KB 506171 1 4KB 506173 3 12KB 506177 7 28KB 506185 7 28KB 506193 7 28KB 506201 1 4KB 506203 1 4KB 506205 3 12KB 506221 1 4KB 506233 1 4KB 506235 1 4KB 506237 1 4KB 506239 1 4KB 506241 1 4KB 506249 7 28KB 506257 7 28KB 506273 3 12KB 506289 7 28KB 506305 3 12KB 506309 3 12KB 506313 7 28KB 506327 1 4KB 506329 7 28KB 506337 3 12KB 506345 7 28KB 506353 1 4KB 506357 3 12KB 506361 7 28KB 506401 7 28KB 506417 7 28KB 506485 3 12KB 506489 3 12KB 506493 3 12KB 507625 7 28KB 507857 7 28KB 507873 7 28KB 507881 7 28KB 507905 7 28KB 507921 7 28KB 507937 7 28KB 507949 3 12KB 507961 3 12KB 507993 7 28KB 508009 7 28KB 508017 7 28KB 508929 7 28KB 508937 7 28KB 508953 7 28KB 509049 7 28KB 509089 3 12KB 509093 3 12KB 509097 3 12KB 509193 7 28KB 509201 7 28KB 509209 7 28KB 509225 7 28KB 509245 3 12KB 509253 3 12KB 509273 7 28KB 509489 7 28KB 509497 7 28KB 509965 3 12KB 509969 7 28KB 509985 7 28KB 510023 1 4KB 510025 7 28KB 510037 3 12KB 510041 7 28KB 510049 7 28KB 510057 7 28KB 510065 7 28KB 510081 7 28KB 510089 7 28KB 510117 3 12KB 510121 7 28KB 510287 1 4KB 510293 3 12KB 510319 1 4KB 510327 1 4KB 510417 7 28KB 510433 7 28KB 510633 7 28KB 510657 3 12KB 510749 1 4KB 510873 7 28KB 510957 3 12KB 510977 3 12KB 511013 3 12KB 511017 7 28KB 511033 7 28KB 511041 3 12KB 511049 7 28KB 511057 3 12KB 511061 3 12KB 511065 3 12KB 511069 3 12KB 511073 3 12KB 511077 3 12KB 511081 3 12KB 511085 3 12KB 511089 3 12KB 511093 3 12KB 511097 3 12KB 511101 3 12KB 511105 3 12KB 511109 3 12KB 511113 3 12KB 511117 3 12KB 511121 3 12KB 511125 3 12KB 511129 3 12KB 511133 3 12KB 511137 3 12KB 511141 3 12KB 511145 3 12KB 511149 3 12KB 511153 7 28KB 511161 1 4KB 511163 1 4KB 511165 3 12KB 511169 3 12KB 511173 1 4KB 511177 7 28KB 511185 7 28KB 511193 7 28KB 511207 1 4KB 511215 1 4KB 511217 7 28KB 511225 7 28KB 511233 1 4KB 511241 7 28KB 511249 7 28KB 511257 7 28KB 511265 3 12KB 511269 3 12KB 511273 7 28KB 511281 3 12KB 511285 3 12KB 511289 3 12KB 511293 3 12KB 511297 3 12KB 511301 1 4KB 511305 7 28KB 511325 3 12KB 511329 3 12KB 511333 3 12KB 511337 3 12KB 511341 3 12KB 511345 3 12KB 511349 3 12KB 511353 3 12KB 511357 3 12KB 511361 3 12KB 511365 3 12KB 511369 3 12KB 511373 3 12KB 511377 3 12KB 511381 3 12KB 511385 3 12KB 511389 3 12KB 511393 3 12KB 511397 3 12KB 511401 3 12KB 511405 3 12KB 511409 3 12KB 511413 3 12KB 511417 3 12KB 511421 3 12KB 511425 3 12KB 511429 3 12KB 511433 3 12KB 511437 3 12KB 511465 3 12KB 511469 3 12KB 511473 3 12KB 511477 3 12KB 511481 3 12KB 511485 3 12KB 511489 3 12KB 511493 3 12KB 511497 3 12KB 511501 3 12KB 511505 3 12KB 511509 3 12KB 511513 3 12KB 511517 3 12KB 511521 3 12KB 511525 3 12KB 511529 3 12KB 511533 3 12KB 511537 3 12KB 511541 3 12KB 511545 3 12KB 511549 3 12KB 511553 3 12KB 511557 3 12KB 511561 3 12KB 511565 3 12KB 511569 3 12KB 511573 3 12KB 511577 3 12KB 511581 3 12KB 511585 3 12KB 511589 3 12KB 511593 3 12KB 511597 3 12KB 511601 3 12KB 511605 3 12KB 511641 3 12KB 511645 3 12KB 511649 3 12KB 511653 3 12KB 511657 3 12KB 511661 3 12KB 511665 3 12KB 511669 3 12KB 511673 3 12KB 511677 3 12KB 511681 3 12KB 511685 3 12KB 511689 3 12KB 511693 3 12KB 511697 3 12KB 511701 3 12KB 511705 3 12KB 511709 3 12KB 511713 3 12KB 511717 3 12KB 511721 3 12KB 511725 3 12KB 511729 3 12KB 511733 3 12KB 511737 3 12KB 511741 3 12KB 511745 3 12KB 511749 3 12KB 511753 3 12KB 511757 3 12KB 511761 3 12KB 511765 3 12KB 511769 3 12KB 511773 3 12KB 511777 3 12KB 511813 3 12KB 511817 3 12KB 511821 3 12KB 511825 3 12KB 511829 3 12KB 511833 3 12KB 511837 3 12KB 511841 3 12KB 511845 3 12KB 511849 3 12KB 511853 3 12KB 511857 3 12KB 511861 3 12KB 511865 3 12KB 511869 3 12KB 511873 3 12KB 511877 3 12KB 511881 3 12KB 511885 3 12KB 511889 3 12KB 511893 3 12KB 511897 3 12KB 511901 3 12KB 511905 3 12KB 511909 3 12KB 511913 3 12KB 511917 3 12KB 511921 3 12KB 511925 3 12KB 511929 3 12KB 511933 3 12KB 511937 3 12KB 511941 3 12KB 511945 3 12KB 511949 3 12KB 511985 3 12KB 511989 3 12KB 511993 3 12KB 511997 3 12KB 512005 3 12KB 512045 1 4KB 512049 7 28KB 512553 7 28KB 512837 1 4KB 512839 1 4KB 512841 1 4KB 512843 1 4KB 512845 3 12KB 512945 7 28KB 512953 3 12KB 512957 3 12KB 512969 7 28KB 512977 7 28KB 512989 3 12KB 512993 7 28KB ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-16 2:41 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-16 2:41 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Wed, Apr 15, 2009 at 09:57:49PM +0800, Andi Kleen wrote: > > That's pretty good separations. I guess it would be convenient to make the > > extra kernel flags available under CONFIG_DEBUG_KERNEL? > > Yes. > > BTW an alternative would be just someone implementing a suitable > command/macro in crash(1) and tell the kernel hackers to run that on > /proc/kcore. That would have the advantage to not require code. Hmm, that would be horrible to code/maintain. One major purpose of /proc/kpageflags is to export the unstable kernel page flag bits as stable ones to user space. Note that the exact internal flag bits can not only change slowly with kernel versions, but more likely with different kconfig combinations. > > > > > > > - PG_compound > > > > > > I would combine these three into a pseudo "large page" flag. > > > > Very neat idea! Patch updated accordingly. > > > > However - one pity I observed: > > > > # ./page-areas 0x008000 > > offset len KB > > 3088 4 16KB > > > > We can no longer tell if the above line means one 4-page hugepage, or two > > 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block > > There's only a single size (2 or 4MB), at worst two. Sorry I was not only referring to the CPU huge pages, but also the more general compound pages retrieved with __GFP_COMP, by SLUB and many drivers, in various orders. After adding PG_COMPOUND_TAIL: # ./page-types flags page-count MB symbolic-flags long-symbolic-flags 0x000000004000 491394 1919 ______________r____________ reserved 0x000000008000 15 0 _______________o___________ compound 0x004000008000 4293 16 _______________o__________T compound,compound_tail 0x000000008014 1 0 __R_D__________o___________ referenced,dirty,compound 0x004000008014 4 0 __R_D__________o__________T referenced,dirty,compound,compound_tail 0x000000000020 1 0 _____l_____________________ lru 0x000000000028 2630 10 ___U_l_____________________ uptodate,lru 0x00000000002c 5244 20 __RU_l_____________________ referenced,uptodate,lru 0x000000000068 240 0 ___U_lA____________________ uptodate,lru,active 0x00000000006c 924 3 __RU_lA____________________ referenced,uptodate,lru,active 0x000000002078 1 0 ___UDlA______b_____________ uptodate,dirty,lru,active,swapbacked 0x00000000207c 17 0 __RUDlA______b_____________ referenced,uptodate,dirty,lru,active,swapbacked 0x000000000228 49 0 ___U_l___x_________________ uptodate,lru,reclaim 0x000000000400 528 2 __________B________________ buddy 0x000000000804 1 0 __R________m_______________ referenced,mmap 0x000000002808 10 0 ___U_______m_b_____________ uptodate,mmap,swapbacked 0x000000000828 1140 4 ___U_l_____m_______________ uptodate,lru,mmap 0x00000000082c 280 1 __RU_l_____m_______________ referenced,uptodate,lru,mmap 0x000000002868 3658 14 ___U_lA____m_b_____________ uptodate,lru,active,mmap,swapbacked 0x000000000868 367 1 ___U_lA____m_______________ uptodate,lru,active,mmap 0x00000000086c 622 2 __RU_lA____m_______________ referenced,uptodate,lru,active,mmap 0x00000000286c 28 0 __RU_lA____m_b_____________ referenced,uptodate,lru,active,mmap,swapbacked 0x000000002878 2 0 ___UDlA____m_b_____________ uptodate,dirty,lru,active,mmap,swapbacked 0x000000000880 1497 5 _______S___m_______________ slab,mmap 0x000000008880 914 3 _______S___m___o___________ slab,mmap,compound 0x0000000008c0 49 0 ______AS___m_______________ active,slab,mmap 0x0000000088c0 59 0 ______AS___m___o___________ active,slab,mmap,compound total 513968 2007 It's interesting that the compound heads and compound tails don't match (even closely). There are 16 compound head pages, but 989 segments of compound tails: root@hp /home/wfg# ./page-areas =0x000000008000|wc -l 16 root@hp /home/wfg# ./page-areas =0x004000008000|wc -l 989 Followed are their detailed locations. Did we found a bug? ;-) Thanks, Fengguang --- root@hp /home/wfg# ./page-areas =0x000000008000 offset len KB 3088 1 4KB 497664 1 4KB 500128 1 4KB 502952 1 4KB 503056 1 4KB 503264 1 4KB 504860 1 4KB 504960 1 4KB 504964 1 4KB 506204 1 4KB 506272 1 4KB 506304 1 4KB 509088 1 4KB 509964 1 4KB 512988 1 4KB root@hp /home/wfg# ./page-areas =0x004000008000 offset len KB 3089 3 12KB 487437 3 12KB 487441 3 12KB 487445 3 12KB 487449 3 12KB 487453 3 12KB 487457 3 12KB 487491 1 4KB 487497 7 28KB 487505 7 28KB 487513 7 28KB 487521 7 28KB 487529 7 28KB 487537 7 28KB 487545 7 28KB 487577 1 4KB 490497 3 12KB 490509 3 12KB 490521 7 28KB 490529 3 12KB 490533 3 12KB 490537 3 12KB 490541 3 12KB 490545 3 12KB 490549 3 12KB 490557 3 12KB 490565 3 12KB 490569 3 12KB 490573 3 12KB 490577 3 12KB 490581 3 12KB 490585 3 12KB 490593 3 12KB 490597 3 12KB 490601 3 12KB 490605 3 12KB 490609 3 12KB 490613 3 12KB 490617 3 12KB 490633 3 12KB 490637 3 12KB 490641 3 12KB 490645 3 12KB 490649 3 12KB 490653 3 12KB 490665 7 28KB 490673 7 28KB 490713 1 4KB 490715 1 4KB 490717 3 12KB 490721 7 28KB 490729 7 28KB 490737 1 4KB 490739 1 4KB 490741 3 12KB 490745 7 28KB 490753 3 12KB 490757 3 12KB 490761 7 28KB 490769 7 28KB 490777 7 28KB 490785 7 28KB 490793 7 28KB 490801 3 12KB 490823 1 4KB 490825 7 28KB 490833 7 28KB 490841 3 12KB 490845 1 4KB 490847 1 4KB 490849 7 28KB 490857 7 28KB 490865 1 4KB 490873 7 28KB 490881 7 28KB 490889 7 28KB 490897 7 28KB 490905 7 28KB 490913 7 28KB 490921 7 28KB 490929 7 28KB 490937 7 28KB 490945 7 28KB 490953 7 28KB 490961 7 28KB 490969 7 28KB 490977 7 28KB 490985 7 28KB 490993 7 28KB 491001 7 28KB 491009 7 28KB 491033 7 28KB 491067 1 4KB 491069 1 4KB 491073 7 28KB 491081 7 28KB 491089 7 28KB 491097 7 28KB 491105 7 28KB 491113 7 28KB 491121 7 28KB 491129 7 28KB 491137 7 28KB 491145 7 28KB 491153 7 28KB 491161 7 28KB 491169 7 28KB 491177 7 28KB 491185 7 28KB 491193 7 28KB 491201 7 28KB 491209 7 28KB 491217 7 28KB 491225 7 28KB 491233 7 28KB 491241 7 28KB 491249 7 28KB 491257 7 28KB 491265 7 28KB 491273 7 28KB 491281 7 28KB 491289 7 28KB 491297 7 28KB 491305 7 28KB 491313 7 28KB 491321 7 28KB 491329 7 28KB 491337 7 28KB 491345 7 28KB 491353 7 28KB 491361 7 28KB 491369 7 28KB 491377 7 28KB 491385 7 28KB 491393 7 28KB 491401 7 28KB 491409 7 28KB 491417 7 28KB 491457 7 28KB 491465 7 28KB 496657 7 28KB 496677 3 12KB 496681 7 28KB 496689 7 28KB 496713 7 28KB 496721 7 28KB 496735 1 4KB 497665 31 124KB 497697 7 28KB 497705 7 28KB 497775 1 4KB 497777 7 28KB 497853 3 12KB 497865 7 28KB 498761 3 12KB 498765 3 12KB 498777 1 4KB 498817 7 28KB 498825 7 28KB 498865 1 4KB 498877 3 12KB 498881 1 4KB 498883 1 4KB 498889 7 28KB 498901 3 12KB 498911 1 4KB 498913 7 28KB 498925 3 12KB 498929 7 28KB 498937 7 28KB 498945 3 12KB 498949 3 12KB 498953 3 12KB 498957 3 12KB 498969 7 28KB 498981 3 12KB 498985 3 12KB 499001 7 28KB 499009 7 28KB 499021 1 4KB 499025 7 28KB 499033 7 28KB 499041 7 28KB 499049 7 28KB 499057 7 28KB 499065 7 28KB 499079 1 4KB 499081 3 12KB 499085 3 12KB 499091 1 4KB 499105 7 28KB 499113 7 28KB 499121 7 28KB 499129 7 28KB 499137 3 12KB 499141 1 4KB 499143 1 4KB 499145 7 28KB 499163 1 4KB 499165 3 12KB 499169 3 12KB 499175 1 4KB 499177 7 28KB 499185 3 12KB 499189 3 12KB 499193 7 28KB 499201 7 28KB 499209 7 28KB 499217 7 28KB 499225 3 12KB 499229 3 12KB 499233 7 28KB 499241 3 12KB 499249 3 12KB 499253 3 12KB 499257 3 12KB 499261 3 12KB 499265 3 12KB 499269 3 12KB 499273 3 12KB 499277 3 12KB 499281 3 12KB 499285 3 12KB 499289 3 12KB 499293 3 12KB 499297 3 12KB 499301 3 12KB 499305 3 12KB 499309 3 12KB 499313 3 12KB 499317 3 12KB 499321 3 12KB 499325 3 12KB 499329 3 12KB 499333 3 12KB 499337 3 12KB 499341 3 12KB 499345 3 12KB 499349 3 12KB 499353 3 12KB 499357 3 12KB 499361 3 12KB 499365 3 12KB 499369 3 12KB 499373 3 12KB 499377 3 12KB 499381 3 12KB 499385 3 12KB 499419 1 4KB 499421 3 12KB 499425 3 12KB 499429 3 12KB 499433 3 12KB 499437 3 12KB 499441 3 12KB 499445 3 12KB 499481 3 12KB 499485 3 12KB 499489 3 12KB 499493 3 12KB 499497 3 12KB 499501 3 12KB 499505 3 12KB 499509 3 12KB 499513 1 4KB 499517 3 12KB 499521 3 12KB 499557 3 12KB 499561 3 12KB 499565 3 12KB 499569 3 12KB 499573 3 12KB 499577 3 12KB 499581 3 12KB 499585 3 12KB 499589 3 12KB 499593 3 12KB 499629 3 12KB 499633 3 12KB 499637 3 12KB 499641 3 12KB 499645 3 12KB 499649 3 12KB 499653 3 12KB 499689 3 12KB 499693 3 12KB 499697 3 12KB 499701 3 12KB 499705 3 12KB 499709 3 12KB 499713 7 28KB 499721 7 28KB 499729 7 28KB 499737 7 28KB 499745 7 28KB 499753 7 28KB 499761 7 28KB 499769 7 28KB 499777 7 28KB 499785 7 28KB 499793 7 28KB 499801 7 28KB 499825 7 28KB 499833 7 28KB 499841 7 28KB 499849 7 28KB 499865 7 28KB 499873 7 28KB 499881 7 28KB 499889 7 28KB 499897 7 28KB 499913 7 28KB 499929 7 28KB 499937 7 28KB 499953 7 28KB 499961 7 28KB 499969 7 28KB 499977 7 28KB 499993 7 28KB 500001 7 28KB 500009 7 28KB 500025 7 28KB 500033 7 28KB 500041 7 28KB 500049 7 28KB 500057 7 28KB 500069 11 44KB 500081 7 28KB 500089 7 28KB 500105 7 28KB 500113 7 28KB 500121 7 28KB 500129 15 60KB 500145 7 28KB 500153 7 28KB 500161 7 28KB 500185 7 28KB 500193 7 28KB 500209 7 28KB 500217 7 28KB 500233 7 28KB 500289 7 28KB 500297 7 28KB 500305 7 28KB 500313 7 28KB 500321 7 28KB 500329 7 28KB 500337 7 28KB 500345 7 28KB 500353 7 28KB 500361 7 28KB 500369 7 28KB 500377 7 28KB 500385 7 28KB 500393 7 28KB 500401 7 28KB 500409 7 28KB 500417 7 28KB 500425 7 28KB 500433 7 28KB 500441 7 28KB 500743 1 4KB 500745 7 28KB 500753 7 28KB 500769 7 28KB 500795 1 4KB 500817 7 28KB 500841 7 28KB 500849 7 28KB 500857 7 28KB 500873 7 28KB 500881 7 28KB 500889 7 28KB 500911 1 4KB 500921 7 28KB 500937 7 28KB 500961 7 28KB 500977 7 28KB 500985 7 28KB 501001 7 28KB 501017 7 28KB 501025 7 28KB 501057 7 28KB 501071 1 4KB 501081 7 28KB 501129 7 28KB 501145 7 28KB 501153 7 28KB 501169 7 28KB 501177 7 28KB 501185 7 28KB 501225 7 28KB 501241 7 28KB 501305 1 4KB 501309 3 12KB 501313 1 4KB 501761 3 12KB 501765 3 12KB 501769 3 12KB 501773 3 12KB 501777 3 12KB 501781 3 12KB 501785 3 12KB 501789 3 12KB 501793 3 12KB 501797 3 12KB 501801 3 12KB 501805 3 12KB 501809 3 12KB 501813 3 12KB 501817 3 12KB 501821 3 12KB 501825 3 12KB 501829 3 12KB 501833 3 12KB 501837 3 12KB 501841 3 12KB 501845 3 12KB 501849 3 12KB 501853 3 12KB 501857 3 12KB 501861 3 12KB 501865 3 12KB 501869 3 12KB 501873 3 12KB 501877 3 12KB 501881 3 12KB 501885 3 12KB 501917 3 12KB 501921 3 12KB 501925 3 12KB 501929 3 12KB 501933 3 12KB 501937 3 12KB 501941 3 12KB 501945 3 12KB 501949 3 12KB 501953 3 12KB 501957 3 12KB 501961 3 12KB 501965 3 12KB 501969 3 12KB 501973 3 12KB 501977 3 12KB 501981 3 12KB 501985 3 12KB 501989 3 12KB 501993 3 12KB 501997 3 12KB 502001 3 12KB 502005 3 12KB 502009 3 12KB 502013 3 12KB 502017 3 12KB 502021 3 12KB 502025 3 12KB 502029 3 12KB 502033 3 12KB 502037 3 12KB 502041 3 12KB 502045 3 12KB 502049 3 12KB 502053 3 12KB 502077 3 12KB 502081 3 12KB 502085 3 12KB 502089 3 12KB 502093 3 12KB 502097 3 12KB 502101 3 12KB 502105 3 12KB 502109 3 12KB 502113 3 12KB 502117 3 12KB 502121 3 12KB 502125 3 12KB 502129 3 12KB 502133 3 12KB 502137 3 12KB 502141 3 12KB 502145 3 12KB 502149 3 12KB 502153 3 12KB 502157 3 12KB 502161 3 12KB 502165 3 12KB 502169 3 12KB 502173 3 12KB 502177 3 12KB 502181 3 12KB 502185 3 12KB 502201 3 12KB 502205 3 12KB 502219 1 4KB 502229 3 12KB 502233 3 12KB 502237 1 4KB 502241 3 12KB 502245 3 12KB 502253 3 12KB 502265 3 12KB 502289 3 12KB 502293 3 12KB 502297 3 12KB 502301 3 12KB 502305 3 12KB 502309 3 12KB 502313 3 12KB 502317 3 12KB 502321 3 12KB 502329 3 12KB 502369 3 12KB 502373 3 12KB 502377 3 12KB 502385 7 28KB 502405 3 12KB 502409 3 12KB 502445 3 12KB 502529 1 4KB 502531 1 4KB 502533 3 12KB 502595 1 4KB 502597 3 12KB 502833 7 28KB 502841 7 28KB 502849 7 28KB 502857 7 28KB 502869 1 4KB 502873 7 28KB 502913 7 28KB 502921 7 28KB 502945 7 28KB 502953 3 12KB 502963 1 4KB 502993 7 28KB 503041 7 28KB 503049 7 28KB 503057 7 28KB 503069 3 12KB 503073 7 28KB 503087 1 4KB 503089 7 28KB 503101 3 12KB 503105 7 28KB 503113 1 4KB 503137 7 28KB 503149 1 4KB 503155 1 4KB 503157 3 12KB 503161 7 28KB 503173 1 4KB 503177 7 28KB 503185 7 28KB 503195 1 4KB 503225 7 28KB 503249 7 28KB 503265 3 12KB 503273 7 28KB 503281 3 12KB 503287 1 4KB 503289 7 28KB 503813 3 12KB 503821 3 12KB 503825 7 28KB 503833 1 4KB 503837 1 4KB 503869 3 12KB 503897 7 28KB 503905 7 28KB 503925 3 12KB 503929 7 28KB 503937 7 28KB 503953 7 28KB 503985 7 28KB 503993 7 28KB 504001 7 28KB 504009 3 12KB 504029 3 12KB 504033 7 28KB 504041 7 28KB 504049 7 28KB 504057 7 28KB 504065 7 28KB 504073 7 28KB 504081 7 28KB 504089 7 28KB 504097 7 28KB 504105 7 28KB 504113 1 4KB 504115 1 4KB 504121 7 28KB 504161 7 28KB 504169 7 28KB 504187 1 4KB 504193 7 28KB 504201 7 28KB 504209 7 28KB 504217 7 28KB 504225 7 28KB 504233 7 28KB 504241 7 28KB 504257 7 28KB 504265 7 28KB 504281 1 4KB 504295 1 4KB 504297 7 28KB 504309 3 12KB 504313 7 28KB 504833 7 28KB 504851 1 4KB 504861 3 12KB 504873 7 28KB 504881 1 4KB 504883 1 4KB 504889 7 28KB 504897 7 28KB 504909 3 12KB 504913 3 12KB 504917 1 4KB 504919 1 4KB 504921 1 4KB 504953 7 28KB 504961 3 12KB 504965 3 12KB 504977 7 28KB 504985 7 28KB 504993 7 28KB 505025 7 28KB 505033 7 28KB 505041 7 28KB 505065 3 12KB 505073 3 12KB 505081 7 28KB 505089 7 28KB 505137 7 28KB 505153 7 28KB 505169 7 28KB 505177 7 28KB 505185 7 28KB 505209 7 28KB 505217 7 28KB 505225 7 28KB 505233 7 28KB 505241 7 28KB 505249 7 28KB 505293 3 12KB 505297 7 28KB 505309 3 12KB 505313 7 28KB 505321 7 28KB 505337 1 4KB 505341 1 4KB 505343 1 4KB 505875 1 4KB 505877 1 4KB 505879 1 4KB 505885 3 12KB 505889 7 28KB 505899 1 4KB 505901 1 4KB 505905 7 28KB 505919 1 4KB 505921 7 28KB 505929 1 4KB 505933 3 12KB 505937 7 28KB 505947 1 4KB 505953 7 28KB 505969 7 28KB 505977 7 28KB 505985 1 4KB 505987 1 4KB 505989 1 4KB 505991 1 4KB 505993 1 4KB 505995 1 4KB 506005 1 4KB 506039 1 4KB 506041 7 28KB 506053 1 4KB 506055 1 4KB 506073 7 28KB 506089 1 4KB 506091 1 4KB 506093 1 4KB 506095 1 4KB 506101 1 4KB 506109 1 4KB 506111 1 4KB 506159 1 4KB 506169 1 4KB 506171 1 4KB 506173 3 12KB 506177 7 28KB 506185 7 28KB 506193 7 28KB 506201 1 4KB 506203 1 4KB 506205 3 12KB 506221 1 4KB 506233 1 4KB 506235 1 4KB 506237 1 4KB 506239 1 4KB 506241 1 4KB 506249 7 28KB 506257 7 28KB 506273 3 12KB 506289 7 28KB 506305 3 12KB 506309 3 12KB 506313 7 28KB 506327 1 4KB 506329 7 28KB 506337 3 12KB 506345 7 28KB 506353 1 4KB 506357 3 12KB 506361 7 28KB 506401 7 28KB 506417 7 28KB 506485 3 12KB 506489 3 12KB 506493 3 12KB 507625 7 28KB 507857 7 28KB 507873 7 28KB 507881 7 28KB 507905 7 28KB 507921 7 28KB 507937 7 28KB 507949 3 12KB 507961 3 12KB 507993 7 28KB 508009 7 28KB 508017 7 28KB 508929 7 28KB 508937 7 28KB 508953 7 28KB 509049 7 28KB 509089 3 12KB 509093 3 12KB 509097 3 12KB 509193 7 28KB 509201 7 28KB 509209 7 28KB 509225 7 28KB 509245 3 12KB 509253 3 12KB 509273 7 28KB 509489 7 28KB 509497 7 28KB 509965 3 12KB 509969 7 28KB 509985 7 28KB 510023 1 4KB 510025 7 28KB 510037 3 12KB 510041 7 28KB 510049 7 28KB 510057 7 28KB 510065 7 28KB 510081 7 28KB 510089 7 28KB 510117 3 12KB 510121 7 28KB 510287 1 4KB 510293 3 12KB 510319 1 4KB 510327 1 4KB 510417 7 28KB 510433 7 28KB 510633 7 28KB 510657 3 12KB 510749 1 4KB 510873 7 28KB 510957 3 12KB 510977 3 12KB 511013 3 12KB 511017 7 28KB 511033 7 28KB 511041 3 12KB 511049 7 28KB 511057 3 12KB 511061 3 12KB 511065 3 12KB 511069 3 12KB 511073 3 12KB 511077 3 12KB 511081 3 12KB 511085 3 12KB 511089 3 12KB 511093 3 12KB 511097 3 12KB 511101 3 12KB 511105 3 12KB 511109 3 12KB 511113 3 12KB 511117 3 12KB 511121 3 12KB 511125 3 12KB 511129 3 12KB 511133 3 12KB 511137 3 12KB 511141 3 12KB 511145 3 12KB 511149 3 12KB 511153 7 28KB 511161 1 4KB 511163 1 4KB 511165 3 12KB 511169 3 12KB 511173 1 4KB 511177 7 28KB 511185 7 28KB 511193 7 28KB 511207 1 4KB 511215 1 4KB 511217 7 28KB 511225 7 28KB 511233 1 4KB 511241 7 28KB 511249 7 28KB 511257 7 28KB 511265 3 12KB 511269 3 12KB 511273 7 28KB 511281 3 12KB 511285 3 12KB 511289 3 12KB 511293 3 12KB 511297 3 12KB 511301 1 4KB 511305 7 28KB 511325 3 12KB 511329 3 12KB 511333 3 12KB 511337 3 12KB 511341 3 12KB 511345 3 12KB 511349 3 12KB 511353 3 12KB 511357 3 12KB 511361 3 12KB 511365 3 12KB 511369 3 12KB 511373 3 12KB 511377 3 12KB 511381 3 12KB 511385 3 12KB 511389 3 12KB 511393 3 12KB 511397 3 12KB 511401 3 12KB 511405 3 12KB 511409 3 12KB 511413 3 12KB 511417 3 12KB 511421 3 12KB 511425 3 12KB 511429 3 12KB 511433 3 12KB 511437 3 12KB 511465 3 12KB 511469 3 12KB 511473 3 12KB 511477 3 12KB 511481 3 12KB 511485 3 12KB 511489 3 12KB 511493 3 12KB 511497 3 12KB 511501 3 12KB 511505 3 12KB 511509 3 12KB 511513 3 12KB 511517 3 12KB 511521 3 12KB 511525 3 12KB 511529 3 12KB 511533 3 12KB 511537 3 12KB 511541 3 12KB 511545 3 12KB 511549 3 12KB 511553 3 12KB 511557 3 12KB 511561 3 12KB 511565 3 12KB 511569 3 12KB 511573 3 12KB 511577 3 12KB 511581 3 12KB 511585 3 12KB 511589 3 12KB 511593 3 12KB 511597 3 12KB 511601 3 12KB 511605 3 12KB 511641 3 12KB 511645 3 12KB 511649 3 12KB 511653 3 12KB 511657 3 12KB 511661 3 12KB 511665 3 12KB 511669 3 12KB 511673 3 12KB 511677 3 12KB 511681 3 12KB 511685 3 12KB 511689 3 12KB 511693 3 12KB 511697 3 12KB 511701 3 12KB 511705 3 12KB 511709 3 12KB 511713 3 12KB 511717 3 12KB 511721 3 12KB 511725 3 12KB 511729 3 12KB 511733 3 12KB 511737 3 12KB 511741 3 12KB 511745 3 12KB 511749 3 12KB 511753 3 12KB 511757 3 12KB 511761 3 12KB 511765 3 12KB 511769 3 12KB 511773 3 12KB 511777 3 12KB 511813 3 12KB 511817 3 12KB 511821 3 12KB 511825 3 12KB 511829 3 12KB 511833 3 12KB 511837 3 12KB 511841 3 12KB 511845 3 12KB 511849 3 12KB 511853 3 12KB 511857 3 12KB 511861 3 12KB 511865 3 12KB 511869 3 12KB 511873 3 12KB 511877 3 12KB 511881 3 12KB 511885 3 12KB 511889 3 12KB 511893 3 12KB 511897 3 12KB 511901 3 12KB 511905 3 12KB 511909 3 12KB 511913 3 12KB 511917 3 12KB 511921 3 12KB 511925 3 12KB 511929 3 12KB 511933 3 12KB 511937 3 12KB 511941 3 12KB 511945 3 12KB 511949 3 12KB 511985 3 12KB 511989 3 12KB 511993 3 12KB 511997 3 12KB 512005 3 12KB 512045 1 4KB 512049 7 28KB 512553 7 28KB 512837 1 4KB 512839 1 4KB 512841 1 4KB 512843 1 4KB 512845 3 12KB 512945 7 28KB 512953 3 12KB 512957 3 12KB 512969 7 28KB 512977 7 28KB 512989 3 12KB 512993 7 28KB -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-16 2:41 ` Wu Fengguang @ 2009-04-16 3:54 ` Andi Kleen -1 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-16 3:54 UTC (permalink / raw) To: Wu Fengguang; +Cc: Andi Kleen, KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Thu, Apr 16, 2009 at 10:41:33AM +0800, Wu Fengguang wrote: > On Wed, Apr 15, 2009 at 09:57:49PM +0800, Andi Kleen wrote: > > > That's pretty good separations. I guess it would be convenient to make the > > > extra kernel flags available under CONFIG_DEBUG_KERNEL? > > > > Yes. > > > > BTW an alternative would be just someone implementing a suitable > > command/macro in crash(1) and tell the kernel hackers to run that on > > /proc/kcore. That would have the advantage to not require code. > > Hmm, that would be horrible to code/maintain. i Actually the bits are enums and crash is able to read C type information. > One major purpose of > /proc/kpageflags is to export the unstable kernel page flag bits as > stable ones to user space. That's the first case ("administrator"), but not the second one ("kernel hacker") BTW not saying that crash is the best solution for this, but it's certainly an serious alternative for the kernel hacker case. > Note that the exact internal flag bits can > not only change slowly with kernel versions, but more likely with > different kconfig combinations. Really? The numbers should be the same, at least for a given architecture with 32bit/64bit. > Followed are their detailed locations. Did we found a bug? ;-) I think all pages > 0 in a larger page are tails. But I don't claim to understand all the finer details of compound pages. -Andi ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-16 3:54 ` Andi Kleen 0 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-16 3:54 UTC (permalink / raw) To: Wu Fengguang; +Cc: Andi Kleen, KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Thu, Apr 16, 2009 at 10:41:33AM +0800, Wu Fengguang wrote: > On Wed, Apr 15, 2009 at 09:57:49PM +0800, Andi Kleen wrote: > > > That's pretty good separations. I guess it would be convenient to make the > > > extra kernel flags available under CONFIG_DEBUG_KERNEL? > > > > Yes. > > > > BTW an alternative would be just someone implementing a suitable > > command/macro in crash(1) and tell the kernel hackers to run that on > > /proc/kcore. That would have the advantage to not require code. > > Hmm, that would be horrible to code/maintain. i Actually the bits are enums and crash is able to read C type information. > One major purpose of > /proc/kpageflags is to export the unstable kernel page flag bits as > stable ones to user space. That's the first case ("administrator"), but not the second one ("kernel hacker") BTW not saying that crash is the best solution for this, but it's certainly an serious alternative for the kernel hacker case. > Note that the exact internal flag bits can > not only change slowly with kernel versions, but more likely with > different kconfig combinations. Really? The numbers should be the same, at least for a given architecture with 32bit/64bit. > Followed are their detailed locations. Did we found a bug? ;-) I think all pages > 0 in a larger page are tails. But I don't claim to understand all the finer details of compound pages. -Andi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-16 3:54 ` Andi Kleen @ 2009-04-16 4:43 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-16 4:43 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Thu, Apr 16, 2009 at 11:54:43AM +0800, Andi Kleen wrote: > On Thu, Apr 16, 2009 at 10:41:33AM +0800, Wu Fengguang wrote: > > On Wed, Apr 15, 2009 at 09:57:49PM +0800, Andi Kleen wrote: > > > > That's pretty good separations. I guess it would be convenient to make the > > > > extra kernel flags available under CONFIG_DEBUG_KERNEL? > > > > > > Yes. > > > > > > BTW an alternative would be just someone implementing a suitable > > > command/macro in crash(1) and tell the kernel hackers to run that on > > > /proc/kcore. That would have the advantage to not require code. > > > > Hmm, that would be horrible to code/maintain. i > > Actually the bits are enums and crash is able to read C type > information. Great! That dismissed my main concern with crash. > > One major purpose of > > /proc/kpageflags is to export the unstable kernel page flag bits as > > stable ones to user space. > > That's the first case ("administrator"), but not the second one > ("kernel hacker") > > BTW not saying that crash is the best solution for this, but > it's certainly an serious alternative for the kernel hacker > case. OK. > > Note that the exact internal flag bits can > > not only change slowly with kernel versions, but more likely with > > different kconfig combinations. > > Really? The numbers should be the same, at least for a given > architecture with 32bit/64bit. For example, the presence of CONFIG_PAGEFLAGS_EXTENDED will shift all the following flag bits by 1. #ifdef CONFIG_PAGEFLAGS_EXTENDED PG_head, /* A head page */ PG_tail, /* A tail page */ #else PG_compound, /* A compound page */ #endif PG_swapcache, /* Swap page: swp_entry_t in private */ PG_mappedtodisk, /* Has blocks allocated on-disk */ PG_reclaim, /* To be reclaimed asap */ PG_buddy, /* Page is free, on buddy lists */ PG_swapbacked, /* Page is backed by RAM/swap */ #ifdef CONFIG_UNEVICTABLE_LRU PG_unevictable, /* Page is "unevictable" */ #endif #ifdef CONFIG_HAVE_MLOCKED_PAGE_BIT PG_mlocked, /* Page is vma mlocked */ #endif #ifdef CONFIG_IA64_UNCACHED_ALLOCATOR PG_uncached, /* Page has been mapped as uncached */ #endif __NR_PAGEFLAGS, > > Followed are their detailed locations. Did we found a bug? ;-) > > I think all pages > 0 in a larger page are tails. But I don't > claim to understand all the finer details of compound pages. Right. Tail pages will outnumber head pages. But I found that the tail page _ranges_ greatly outnumber head pages. There should be exactly one tail page range for one head page. Thanks, Fengguang ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-16 4:43 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-16 4:43 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Thu, Apr 16, 2009 at 11:54:43AM +0800, Andi Kleen wrote: > On Thu, Apr 16, 2009 at 10:41:33AM +0800, Wu Fengguang wrote: > > On Wed, Apr 15, 2009 at 09:57:49PM +0800, Andi Kleen wrote: > > > > That's pretty good separations. I guess it would be convenient to make the > > > > extra kernel flags available under CONFIG_DEBUG_KERNEL? > > > > > > Yes. > > > > > > BTW an alternative would be just someone implementing a suitable > > > command/macro in crash(1) and tell the kernel hackers to run that on > > > /proc/kcore. That would have the advantage to not require code. > > > > Hmm, that would be horrible to code/maintain. i > > Actually the bits are enums and crash is able to read C type > information. Great! That dismissed my main concern with crash. > > One major purpose of > > /proc/kpageflags is to export the unstable kernel page flag bits as > > stable ones to user space. > > That's the first case ("administrator"), but not the second one > ("kernel hacker") > > BTW not saying that crash is the best solution for this, but > it's certainly an serious alternative for the kernel hacker > case. OK. > > Note that the exact internal flag bits can > > not only change slowly with kernel versions, but more likely with > > different kconfig combinations. > > Really? The numbers should be the same, at least for a given > architecture with 32bit/64bit. For example, the presence of CONFIG_PAGEFLAGS_EXTENDED will shift all the following flag bits by 1. #ifdef CONFIG_PAGEFLAGS_EXTENDED PG_head, /* A head page */ PG_tail, /* A tail page */ #else PG_compound, /* A compound page */ #endif PG_swapcache, /* Swap page: swp_entry_t in private */ PG_mappedtodisk, /* Has blocks allocated on-disk */ PG_reclaim, /* To be reclaimed asap */ PG_buddy, /* Page is free, on buddy lists */ PG_swapbacked, /* Page is backed by RAM/swap */ #ifdef CONFIG_UNEVICTABLE_LRU PG_unevictable, /* Page is "unevictable" */ #endif #ifdef CONFIG_HAVE_MLOCKED_PAGE_BIT PG_mlocked, /* Page is vma mlocked */ #endif #ifdef CONFIG_IA64_UNCACHED_ALLOCATOR PG_uncached, /* Page has been mapped as uncached */ #endif __NR_PAGEFLAGS, > > Followed are their detailed locations. Did we found a bug? ;-) > > I think all pages > 0 in a larger page are tails. But I don't > claim to understand all the finer details of compound pages. Right. Tail pages will outnumber head pages. But I found that the tail page _ranges_ greatly outnumber head pages. There should be exactly one tail page range for one head page. Thanks, Fengguang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-15 13:18 ` Wu Fengguang @ 2009-04-16 2:26 ` KOSAKI Motohiro -1 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-16 2:26 UTC (permalink / raw) To: Wu Fengguang; +Cc: kosaki.motohiro, Andi Kleen, Andrew Morton, LKML, linux-mm Hi > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > > Export the following page flags in /proc/kpageflags, > > > > > > just in case they will be useful to someone: > > > > > > > > > > > > - PG_swapcache > > > > > > - PG_swapbacked > > > > > > - PG_mappedtodisk > > > > > > - PG_reserved > > > > PG_reserved should be exported as PG_KERNEL or somesuch. > > PG_KERNEL could be misleading. PG_reserved obviously do not cover all > (or most) kernel pages. So I'd prefer to export PG_reserved as it is. > > It seems that the vast amount of free pages are marked PG_reserved: Can I review the document at first? if no good document for administrator, I can't ack exposing PG_reserved. > # uname -a > Linux hp 2.6.30-rc2 #157 SMP Wed Apr 15 19:37:49 CST 2009 x86_64 GNU/Linux > # echo 1 > /proc/sys/vm/drop_caches > # ./page-types > flags page-count MB symbolic-flags long-symbolic-flags > 0x004000 497474 1943 ______________r_____ reserved > 0x008000 4454 17 _______________o____ compound > 0x008014 5 0 __R_D__________o____ referenced,dirty,compound > 0x000020 1 0 _____l______________ lru > 0x000028 310 1 ___U_l______________ uptodate,lru > 0x00002c 18 0 __RU_l______________ referenced,uptodate,lru > 0x000068 80 0 ___U_lA_____________ uptodate,lru,active > 0x00006c 157 0 __RU_lA_____________ referenced,uptodate,lru,active > 0x002078 1 0 ___UDlA______b______ uptodate,dirty,lru,active,swapbacked > 0x00207c 17 0 __RUDlA______b______ referenced,uptodate,dirty,lru,active,swapbacked > 0x000228 13 0 ___U_l___x__________ uptodate,lru,reclaim > 0x000400 2085 8 __________B_________ buddy "freed" is better? buddy is implementation technique name. > 0x000804 1 0 __R________m________ referenced,mmap > 0x002808 10 0 ___U_______m_b______ uptodate,mmap,swapbacked > 0x000828 1060 4 ___U_l_____m________ uptodate,lru,mmap > 0x00082c 215 0 __RU_l_____m________ referenced,uptodate,lru,mmap > 0x000868 189 0 ___U_lA____m________ uptodate,lru,active,mmap > 0x002868 4187 16 ___U_lA____m_b______ uptodate,lru,active,mmap,swapbacked > 0x00286c 30 0 __RU_lA____m_b______ referenced,uptodate,lru,active,mmap,swapbacked > 0x00086c 1012 3 __RU_lA____m________ referenced,uptodate,lru,active,mmap > 0x002878 3 0 ___UDlA____m_b______ uptodate,dirty,lru,active,mmap,swapbacked > 0x008880 936 3 _______S___m___o____ slab,mmap,compound > 0x000880 1602 6 _______S___m________ slab,mmap please don't display mmap and coumpound. it expose SLUB implentation detail. IOW, if slab flag on, please ignore following flags and mapcount. - PG_active - PG_error - PG_private - PG_compound BTW, if the page don't have PG_lru, following member and flags can be used another meanings. - PG_active - PG_referenced - page::_mapcount - PG_swapbacked - PG_reclaim - PG_unevictable - PG_mlocked and, if the page never interact IO layer, following flags can be used another meanings. - PG_uptodate - PG_dirty > 0x0088c0 59 0 ______AS___m___o____ active,slab,mmap,compound > 0x0008c0 49 0 ______AS___m________ active,slab,mmap > total 513968 2007 And, PageAnon() result seems provide good information if the page stay in lru. > # ./page-areas 0x004000 > offset len KB > 0 15 60KB > 31 4 16KB > 159 97 388KB > 4096 2213 8852KB > 6899 2385 9540KB > 9497 3 12KB > 9728 14528 58112KB > > > > > > > - PG_private > > > > > > - PG_private_2 > > > > > > - PG_owner_priv_1 > > > > > > > > > > > > - PG_head > > > > > > - PG_tail > > > > > > - PG_compound > > > > I would combine these three into a pseudo "large page" flag. > > Very neat idea! Patch updated accordingly. > > However - one pity I observed: > > # ./page-areas 0x008000 > offset len KB > 3088 4 16KB > > We can no longer tell if the above line means one 4-page hugepage, or two > 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block > can help kernel developers. Or will it be ever cared by administrators? > > 341196 2 8KB > 341202 2 8KB > 341262 2 8KB > 341272 8 32KB > 341296 8 32KB > 488448 24 96KB > 488490 2 8KB > 488496 320 1280KB > 488842 2 8KB > 488848 40 160KB > > > > > > > > > > > > > - PG_unevictable > > > > > > - PG_mlocked > > > > > > > > > > > > - PG_poison > > > > PG_poison is also useful to export. But since it depends on my > > patchkit I will pull a patch for that into the HWPOISON series. > > That's not a problem - since the PG_poison line is be protected by > #ifdef CONFIG_MEMORY_FAILURE :-) > > > > > > > - PG_unevictable > > > > > > - PG_mlocked > > > > > > this 9 flags shouldn't exported. > > > I can't imazine administrator use what purpose those flags. > > > > I think an abstraced "PG_pinned" or somesuch flag that combines > > page lock, unevictable, mlocked would be useful for the administrator. > > The PG_PINNED abstraction risks hiding useful information. > The administrator may not only care about the pinned pages, > but also care _why_ they are pinned, i.e. ramfs.. or mlock? > > So it might be good to export them as is, with proper document. > > Here is the v2 patch, with flags for kernel hackers numbered from 32. > Comments are welcome! if you can write good document, PG_unevictable is exportable. but PG_mlock isn't. that's implementation tecknique of efficient unevictable pages for mlock. we can change the future. > Thanks, > Fengguang > --- > > Export all available page flags in /proc/kpageflags, plus two pseudo ones. > This increases the total number of exported page flags to 26. > > TODO: more document > > Cc: Andi Kleen <andi@firstfloor.org> > Cc: Matt Mackall <mpm@selenic.com> > Cc: Alexey Dobriyan <adobriyan@gmail.com> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > --- > fs/proc/page.c | 122 +++++++++++++++++++++++++++++++++++------------ > 1 file changed, 91 insertions(+), 31 deletions(-) > > --- mm.orig/fs/proc/page.c > +++ mm/fs/proc/page.c > @@ -68,20 +68,96 @@ static const struct file_operations proc > > /* These macros are used to decouple internal flags from exported ones */ > > -#define KPF_LOCKED 0 > -#define KPF_ERROR 1 > -#define KPF_REFERENCED 2 > -#define KPF_UPTODATE 3 > -#define KPF_DIRTY 4 > -#define KPF_LRU 5 > -#define KPF_ACTIVE 6 > -#define KPF_SLAB 7 > -#define KPF_WRITEBACK 8 > -#define KPF_RECLAIM 9 > -#define KPF_BUDDY 10 > +#define KPF_LOCKED 0 > +#define KPF_ERROR 1 > +#define KPF_REFERENCED 2 > +#define KPF_UPTODATE 3 > +#define KPF_DIRTY 4 > +#define KPF_LRU 5 > +#define KPF_ACTIVE 6 > +#define KPF_SLAB 7 > +#define KPF_WRITEBACK 8 > +#define KPF_RECLAIM 9 > +#define KPF_BUDDY 10 > + > +/* new additions in 2.6.31 */ > +#define KPF_MMAP 11 > +#define KPF_SWAPCACHE 12 > +#define KPF_SWAPBACKED 13 > +#define KPF_RESERVED 14 > +#define KPF_COMPOUND 15 > +#define KPF_UNEVICTABLE 16 > +#define KPF_MLOCKED 17 > +#define KPF_POISON 18 > +#define KPF_NOPAGE 19 > + > +/* kernel hacking assistances */ > +#define KPF_MAPPEDTODISK 32 > +#define KPF_PRIVATE 33 > +#define KPF_PRIVATE2 34 > +#define KPF_OWNER_PRIVATE 35 > +#define KPF_ARCH 36 > +#define KPF_UNCACHED 37 > > #define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) > > +u64 get_uflags(struct page *page) > +{ > + u64 kflags; > + u64 uflags; > + > + if (!page) > + return 1 << KPF_NOPAGE; > + > + kflags = page->flags; > + uflags = 0; > + > + if (page_mapped(page)) > + uflags |= 1 << KPF_MMAP; > + > + uflags |= kpf_copy_bit(kflags, KPF_LOCKED, PG_locked); > + uflags |= kpf_copy_bit(kflags, KPF_ERROR, PG_error); > + uflags |= kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced); > + uflags |= kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate); > + uflags |= kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty); > + uflags |= kpf_copy_bit(kflags, KPF_LRU, PG_lru) ; > + uflags |= kpf_copy_bit(kflags, KPF_ACTIVE, PG_active); > + uflags |= kpf_copy_bit(kflags, KPF_SLAB, PG_slab); > + uflags |= kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback); > + uflags |= kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim); > + uflags |= kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); > + > + uflags |= kpf_copy_bit(kflags, KPF_SWAPCACHE, PG_swapcache); > + uflags |= kpf_copy_bit(kflags, KPF_SWAPBACKED, PG_swapbacked); > + uflags |= kpf_copy_bit(kflags, KPF_RESERVED, PG_reserved); > +#ifdef CONFIG_PAGEFLAGS_EXTENDED > + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_head); > + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_tail); > +#else > + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_compound); > +#endif > +#ifdef CONFIG_UNEVICTABLE_LRU > + uflags |= kpf_copy_bit(kflags, KPF_UNEVICTABLE, PG_unevictable); > + uflags |= kpf_copy_bit(kflags, KPF_MLOCKED, PG_mlocked); > +#endif > +#ifdef CONFIG_MEMORY_FAILURE > + uflags |= kpf_copy_bit(kflags, KPF_POISON, PG_poison); > +#endif > + > +#ifdef CONFIG_DEBUG_KERNEL > + uflags |= kpf_copy_bit(kflags, KPF_MAPPEDTODISK, PG_mappedtodisk); > + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE, PG_private); > + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE2, PG_private_2); > + uflags |= kpf_copy_bit(kflags, KPF_OWNER_PRIVATE, PG_owner_priv_1); > + uflags |= kpf_copy_bit(kflags, KPF_ARCH, PG_arch_1); > +#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR > + uflags |= kpf_copy_bit(kflags, KPF_UNCACHED, PG_uncached); > +#endif > +#endif > + > + return uflags; > +}; > + > static ssize_t kpageflags_read(struct file *file, char __user *buf, > size_t count, loff_t *ppos) > { > @@ -90,7 +166,6 @@ static ssize_t kpageflags_read(struct fi > unsigned long src = *ppos; > unsigned long pfn; > ssize_t ret = 0; > - u64 kflags, uflags; > > pfn = src / KPMSIZE; > count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); > @@ -98,32 +173,17 @@ static ssize_t kpageflags_read(struct fi > return -EINVAL; > > while (count > 0) { > - ppage = NULL; > if (pfn_valid(pfn)) > ppage = pfn_to_page(pfn); > - pfn++; > - if (!ppage) > - kflags = 0; > else > - kflags = ppage->flags; > - > - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | > - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | > - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | > - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | > - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | > - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | > - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | > - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | > - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | > - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | > - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); > + ppage = NULL; > > - if (put_user(uflags, out++)) { > + if (put_user(get_uflags(ppage), out)) { > ret = -EFAULT; > break; > } > - > + out++; > + pfn++; > count -= KPMSIZE; > } > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-16 2:26 ` KOSAKI Motohiro 0 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-16 2:26 UTC (permalink / raw) To: Wu Fengguang; +Cc: kosaki.motohiro, Andi Kleen, Andrew Morton, LKML, linux-mm Hi > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > > Export the following page flags in /proc/kpageflags, > > > > > > just in case they will be useful to someone: > > > > > > > > > > > > - PG_swapcache > > > > > > - PG_swapbacked > > > > > > - PG_mappedtodisk > > > > > > - PG_reserved > > > > PG_reserved should be exported as PG_KERNEL or somesuch. > > PG_KERNEL could be misleading. PG_reserved obviously do not cover all > (or most) kernel pages. So I'd prefer to export PG_reserved as it is. > > It seems that the vast amount of free pages are marked PG_reserved: Can I review the document at first? if no good document for administrator, I can't ack exposing PG_reserved. > # uname -a > Linux hp 2.6.30-rc2 #157 SMP Wed Apr 15 19:37:49 CST 2009 x86_64 GNU/Linux > # echo 1 > /proc/sys/vm/drop_caches > # ./page-types > flags page-count MB symbolic-flags long-symbolic-flags > 0x004000 497474 1943 ______________r_____ reserved > 0x008000 4454 17 _______________o____ compound > 0x008014 5 0 __R_D__________o____ referenced,dirty,compound > 0x000020 1 0 _____l______________ lru > 0x000028 310 1 ___U_l______________ uptodate,lru > 0x00002c 18 0 __RU_l______________ referenced,uptodate,lru > 0x000068 80 0 ___U_lA_____________ uptodate,lru,active > 0x00006c 157 0 __RU_lA_____________ referenced,uptodate,lru,active > 0x002078 1 0 ___UDlA______b______ uptodate,dirty,lru,active,swapbacked > 0x00207c 17 0 __RUDlA______b______ referenced,uptodate,dirty,lru,active,swapbacked > 0x000228 13 0 ___U_l___x__________ uptodate,lru,reclaim > 0x000400 2085 8 __________B_________ buddy "freed" is better? buddy is implementation technique name. > 0x000804 1 0 __R________m________ referenced,mmap > 0x002808 10 0 ___U_______m_b______ uptodate,mmap,swapbacked > 0x000828 1060 4 ___U_l_____m________ uptodate,lru,mmap > 0x00082c 215 0 __RU_l_____m________ referenced,uptodate,lru,mmap > 0x000868 189 0 ___U_lA____m________ uptodate,lru,active,mmap > 0x002868 4187 16 ___U_lA____m_b______ uptodate,lru,active,mmap,swapbacked > 0x00286c 30 0 __RU_lA____m_b______ referenced,uptodate,lru,active,mmap,swapbacked > 0x00086c 1012 3 __RU_lA____m________ referenced,uptodate,lru,active,mmap > 0x002878 3 0 ___UDlA____m_b______ uptodate,dirty,lru,active,mmap,swapbacked > 0x008880 936 3 _______S___m___o____ slab,mmap,compound > 0x000880 1602 6 _______S___m________ slab,mmap please don't display mmap and coumpound. it expose SLUB implentation detail. IOW, if slab flag on, please ignore following flags and mapcount. - PG_active - PG_error - PG_private - PG_compound BTW, if the page don't have PG_lru, following member and flags can be used another meanings. - PG_active - PG_referenced - page::_mapcount - PG_swapbacked - PG_reclaim - PG_unevictable - PG_mlocked and, if the page never interact IO layer, following flags can be used another meanings. - PG_uptodate - PG_dirty > 0x0088c0 59 0 ______AS___m___o____ active,slab,mmap,compound > 0x0008c0 49 0 ______AS___m________ active,slab,mmap > total 513968 2007 And, PageAnon() result seems provide good information if the page stay in lru. > # ./page-areas 0x004000 > offset len KB > 0 15 60KB > 31 4 16KB > 159 97 388KB > 4096 2213 8852KB > 6899 2385 9540KB > 9497 3 12KB > 9728 14528 58112KB > > > > > > > - PG_private > > > > > > - PG_private_2 > > > > > > - PG_owner_priv_1 > > > > > > > > > > > > - PG_head > > > > > > - PG_tail > > > > > > - PG_compound > > > > I would combine these three into a pseudo "large page" flag. > > Very neat idea! Patch updated accordingly. > > However - one pity I observed: > > # ./page-areas 0x008000 > offset len KB > 3088 4 16KB > > We can no longer tell if the above line means one 4-page hugepage, or two > 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block > can help kernel developers. Or will it be ever cared by administrators? > > 341196 2 8KB > 341202 2 8KB > 341262 2 8KB > 341272 8 32KB > 341296 8 32KB > 488448 24 96KB > 488490 2 8KB > 488496 320 1280KB > 488842 2 8KB > 488848 40 160KB > > > > > > > > > > > > > - PG_unevictable > > > > > > - PG_mlocked > > > > > > > > > > > > - PG_poison > > > > PG_poison is also useful to export. But since it depends on my > > patchkit I will pull a patch for that into the HWPOISON series. > > That's not a problem - since the PG_poison line is be protected by > #ifdef CONFIG_MEMORY_FAILURE :-) > > > > > > > - PG_unevictable > > > > > > - PG_mlocked > > > > > > this 9 flags shouldn't exported. > > > I can't imazine administrator use what purpose those flags. > > > > I think an abstraced "PG_pinned" or somesuch flag that combines > > page lock, unevictable, mlocked would be useful for the administrator. > > The PG_PINNED abstraction risks hiding useful information. > The administrator may not only care about the pinned pages, > but also care _why_ they are pinned, i.e. ramfs.. or mlock? > > So it might be good to export them as is, with proper document. > > Here is the v2 patch, with flags for kernel hackers numbered from 32. > Comments are welcome! if you can write good document, PG_unevictable is exportable. but PG_mlock isn't. that's implementation tecknique of efficient unevictable pages for mlock. we can change the future. > Thanks, > Fengguang > --- > > Export all available page flags in /proc/kpageflags, plus two pseudo ones. > This increases the total number of exported page flags to 26. > > TODO: more document > > Cc: Andi Kleen <andi@firstfloor.org> > Cc: Matt Mackall <mpm@selenic.com> > Cc: Alexey Dobriyan <adobriyan@gmail.com> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > --- > fs/proc/page.c | 122 +++++++++++++++++++++++++++++++++++------------ > 1 file changed, 91 insertions(+), 31 deletions(-) > > --- mm.orig/fs/proc/page.c > +++ mm/fs/proc/page.c > @@ -68,20 +68,96 @@ static const struct file_operations proc > > /* These macros are used to decouple internal flags from exported ones */ > > -#define KPF_LOCKED 0 > -#define KPF_ERROR 1 > -#define KPF_REFERENCED 2 > -#define KPF_UPTODATE 3 > -#define KPF_DIRTY 4 > -#define KPF_LRU 5 > -#define KPF_ACTIVE 6 > -#define KPF_SLAB 7 > -#define KPF_WRITEBACK 8 > -#define KPF_RECLAIM 9 > -#define KPF_BUDDY 10 > +#define KPF_LOCKED 0 > +#define KPF_ERROR 1 > +#define KPF_REFERENCED 2 > +#define KPF_UPTODATE 3 > +#define KPF_DIRTY 4 > +#define KPF_LRU 5 > +#define KPF_ACTIVE 6 > +#define KPF_SLAB 7 > +#define KPF_WRITEBACK 8 > +#define KPF_RECLAIM 9 > +#define KPF_BUDDY 10 > + > +/* new additions in 2.6.31 */ > +#define KPF_MMAP 11 > +#define KPF_SWAPCACHE 12 > +#define KPF_SWAPBACKED 13 > +#define KPF_RESERVED 14 > +#define KPF_COMPOUND 15 > +#define KPF_UNEVICTABLE 16 > +#define KPF_MLOCKED 17 > +#define KPF_POISON 18 > +#define KPF_NOPAGE 19 > + > +/* kernel hacking assistances */ > +#define KPF_MAPPEDTODISK 32 > +#define KPF_PRIVATE 33 > +#define KPF_PRIVATE2 34 > +#define KPF_OWNER_PRIVATE 35 > +#define KPF_ARCH 36 > +#define KPF_UNCACHED 37 > > #define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) > > +u64 get_uflags(struct page *page) > +{ > + u64 kflags; > + u64 uflags; > + > + if (!page) > + return 1 << KPF_NOPAGE; > + > + kflags = page->flags; > + uflags = 0; > + > + if (page_mapped(page)) > + uflags |= 1 << KPF_MMAP; > + > + uflags |= kpf_copy_bit(kflags, KPF_LOCKED, PG_locked); > + uflags |= kpf_copy_bit(kflags, KPF_ERROR, PG_error); > + uflags |= kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced); > + uflags |= kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate); > + uflags |= kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty); > + uflags |= kpf_copy_bit(kflags, KPF_LRU, PG_lru) ; > + uflags |= kpf_copy_bit(kflags, KPF_ACTIVE, PG_active); > + uflags |= kpf_copy_bit(kflags, KPF_SLAB, PG_slab); > + uflags |= kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback); > + uflags |= kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim); > + uflags |= kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); > + > + uflags |= kpf_copy_bit(kflags, KPF_SWAPCACHE, PG_swapcache); > + uflags |= kpf_copy_bit(kflags, KPF_SWAPBACKED, PG_swapbacked); > + uflags |= kpf_copy_bit(kflags, KPF_RESERVED, PG_reserved); > +#ifdef CONFIG_PAGEFLAGS_EXTENDED > + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_head); > + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_tail); > +#else > + uflags |= kpf_copy_bit(kflags, KPF_COMPOUND, PG_compound); > +#endif > +#ifdef CONFIG_UNEVICTABLE_LRU > + uflags |= kpf_copy_bit(kflags, KPF_UNEVICTABLE, PG_unevictable); > + uflags |= kpf_copy_bit(kflags, KPF_MLOCKED, PG_mlocked); > +#endif > +#ifdef CONFIG_MEMORY_FAILURE > + uflags |= kpf_copy_bit(kflags, KPF_POISON, PG_poison); > +#endif > + > +#ifdef CONFIG_DEBUG_KERNEL > + uflags |= kpf_copy_bit(kflags, KPF_MAPPEDTODISK, PG_mappedtodisk); > + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE, PG_private); > + uflags |= kpf_copy_bit(kflags, KPF_PRIVATE2, PG_private_2); > + uflags |= kpf_copy_bit(kflags, KPF_OWNER_PRIVATE, PG_owner_priv_1); > + uflags |= kpf_copy_bit(kflags, KPF_ARCH, PG_arch_1); > +#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR > + uflags |= kpf_copy_bit(kflags, KPF_UNCACHED, PG_uncached); > +#endif > +#endif > + > + return uflags; > +}; > + > static ssize_t kpageflags_read(struct file *file, char __user *buf, > size_t count, loff_t *ppos) > { > @@ -90,7 +166,6 @@ static ssize_t kpageflags_read(struct fi > unsigned long src = *ppos; > unsigned long pfn; > ssize_t ret = 0; > - u64 kflags, uflags; > > pfn = src / KPMSIZE; > count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); > @@ -98,32 +173,17 @@ static ssize_t kpageflags_read(struct fi > return -EINVAL; > > while (count > 0) { > - ppage = NULL; > if (pfn_valid(pfn)) > ppage = pfn_to_page(pfn); > - pfn++; > - if (!ppage) > - kflags = 0; > else > - kflags = ppage->flags; > - > - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | > - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | > - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | > - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | > - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | > - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | > - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | > - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | > - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | > - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | > - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); > + ppage = NULL; > > - if (put_user(uflags, out++)) { > + if (put_user(get_uflags(ppage), out)) { > ret = -EFAULT; > break; > } > - > + out++; > + pfn++; > count -= KPMSIZE; > } > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-16 2:26 ` KOSAKI Motohiro @ 2009-04-16 3:49 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-16 3:49 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andi Kleen, Andrew Morton, LKML, linux-mm On Thu, Apr 16, 2009 at 10:26:51AM +0800, KOSAKI Motohiro wrote: > tatus: RO > Content-Length: 13245 > Lines: 380 > > Hi > > > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > > > Export the following page flags in /proc/kpageflags, > > > > > > > just in case they will be useful to someone: > > > > > > > > > > > > > > - PG_swapcache > > > > > > > - PG_swapbacked > > > > > > > - PG_mappedtodisk > > > > > > > - PG_reserved > > > > > > PG_reserved should be exported as PG_KERNEL or somesuch. > > > > PG_KERNEL could be misleading. PG_reserved obviously do not cover all > > (or most) kernel pages. So I'd prefer to export PG_reserved as it is. > > > > It seems that the vast amount of free pages are marked PG_reserved: > > Can I review the document at first? > if no good document for administrator, I can't ack exposing PG_reserved. btw, is this the expected behavior to mark so many free pages as PG_reserved? Last time I looked at it, in 2.6.27, the free pages simply don't have any flags set. //Or maybe it's a false reporting of my tool. Will double check. > > # uname -a > > Linux hp 2.6.30-rc2 #157 SMP Wed Apr 15 19:37:49 CST 2009 x86_64 GNU/Linux > > # echo 1 > /proc/sys/vm/drop_caches > > # ./page-types > > flags page-count MB symbolic-flags long-symbolic-flags > > 0x004000 497474 1943 ______________r_____ reserved > > 0x008000 4454 17 _______________o____ compound > > 0x008014 5 0 __R_D__________o____ referenced,dirty,compound > > 0x000020 1 0 _____l______________ lru > > 0x000028 310 1 ___U_l______________ uptodate,lru > > 0x00002c 18 0 __RU_l______________ referenced,uptodate,lru > > 0x000068 80 0 ___U_lA_____________ uptodate,lru,active > > 0x00006c 157 0 __RU_lA_____________ referenced,uptodate,lru,active > > 0x002078 1 0 ___UDlA______b______ uptodate,dirty,lru,active,swapbacked > > 0x00207c 17 0 __RUDlA______b______ referenced,uptodate,dirty,lru,active,swapbacked > > 0x000228 13 0 ___U_l___x__________ uptodate,lru,reclaim > > 0x000400 2085 8 __________B_________ buddy > > "freed" is better? > buddy is implementation technique name. Not compellingly better :-) I'd expect BUDDY to be a well recognized technique, something close to LRU. PG_BUDDY could be documented as: this page is owned by the buddy system, which manages free memory. PG_FREED may seem more newbie friendly, but there will be the classical newbie question: "Why so few freed pages?!" ;-) It's not likely that an administrator not understanding BUDDY will understand many of the other exported page flags. He will have to query the document anyway. And exporting PG_buddy as it is could be the best option for proficient users. > > 0x000804 1 0 __R________m________ referenced,mmap > > 0x002808 10 0 ___U_______m_b______ uptodate,mmap,swapbacked > > 0x000828 1060 4 ___U_l_____m________ uptodate,lru,mmap > > 0x00082c 215 0 __RU_l_____m________ referenced,uptodate,lru,mmap > > 0x000868 189 0 ___U_lA____m________ uptodate,lru,active,mmap > > 0x002868 4187 16 ___U_lA____m_b______ uptodate,lru,active,mmap,swapbacked > > 0x00286c 30 0 __RU_lA____m_b______ referenced,uptodate,lru,active,mmap,swapbacked > > 0x00086c 1012 3 __RU_lA____m________ referenced,uptodate,lru,active,mmap > > 0x002878 3 0 ___UDlA____m_b______ uptodate,dirty,lru,active,mmap,swapbacked > > 0x008880 936 3 _______S___m___o____ slab,mmap,compound > > 0x000880 1602 6 _______S___m________ slab,mmap > > please don't display mmap and coumpound. it expose SLUB implentation detail. > IOW, if slab flag on, please ignore following flags and mapcount. > - PG_active > - PG_error > - PG_private > - PG_compound > > BTW, if the page don't have PG_lru, following member and flags can be used another meanings. > - PG_active > - PG_referenced > - page::_mapcount > - PG_swapbacked > - PG_reclaim > - PG_unevictable > - PG_mlocked > > and, if the page never interact IO layer, following flags can be used another meanings. > - PG_uptodate > - PG_dirty Good point. I also noticed many of these conditional flags. The perceived solution would be to do some filtering if !CONFIG_DEBUG_KERNEL, to not confuse too many administrators. For kernel developers we want to be faithful :-) > > > 0x0088c0 59 0 ______AS___m___o____ active,slab,mmap,compound > > 0x0008c0 49 0 ______AS___m________ active,slab,mmap > > total 513968 2007 > > > And, PageAnon() result seems provide good information if the page stay in lru. Good point! Will add this bit. > > # ./page-areas 0x004000 > > offset len KB > > 0 15 60KB > > 31 4 16KB > > 159 97 388KB > > 4096 2213 8852KB > > 6899 2385 9540KB > > 9497 3 12KB > > 9728 14528 58112KB > > > > > > > > > - PG_private > > > > > > > - PG_private_2 > > > > > > > - PG_owner_priv_1 > > > > > > > > > > > > > > - PG_head > > > > > > > - PG_tail > > > > > > > - PG_compound > > > > > > I would combine these three into a pseudo "large page" flag. > > > > Very neat idea! Patch updated accordingly. > > > > However - one pity I observed: > > > > # ./page-areas 0x008000 > > offset len KB > > 3088 4 16KB > > > > We can no longer tell if the above line means one 4-page hugepage, or two > > 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block > > can help kernel developers. Or will it be ever cared by administrators? > > > > 341196 2 8KB > > 341202 2 8KB > > 341262 2 8KB > > 341272 8 32KB > > 341296 8 32KB > > 488448 24 96KB > > 488490 2 8KB > > 488496 320 1280KB > > 488842 2 8KB > > 488848 40 160KB > > > > > > > > > > > > > > > > - PG_unevictable > > > > > > > - PG_mlocked > > > > > > > > > > > > > > - PG_poison > > > > > > PG_poison is also useful to export. But since it depends on my > > > patchkit I will pull a patch for that into the HWPOISON series. > > > > That's not a problem - since the PG_poison line is be protected by > > #ifdef CONFIG_MEMORY_FAILURE :-) > > > > > > > > > - PG_unevictable > > > > > > > - PG_mlocked > > > > > > > > this 9 flags shouldn't exported. > > > > I can't imazine administrator use what purpose those flags. > > > > > > I think an abstraced "PG_pinned" or somesuch flag that combines > > > page lock, unevictable, mlocked would be useful for the administrator. > > > > The PG_PINNED abstraction risks hiding useful information. > > The administrator may not only care about the pinned pages, > > but also care _why_ they are pinned, i.e. ramfs.. or mlock? > > > > So it might be good to export them as is, with proper document. > > > > Here is the v2 patch, with flags for kernel hackers numbered from 32. > > Comments are welcome! > > if you can write good document, PG_unevictable is exportable. > but PG_mlock isn't. > > that's implementation tecknique of efficient unevictable pages for mlock. > we can change the future. Yup. That's in line with my vague feeling. For PG_unevictable we can say that the page is owned by the unevictable (non-)lru and not a candidate for LRU page reclaims. But for PG_mlock it's more about an assistant for kernel optimizations and there are no guarantees... Thanks, Fengguang ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-16 3:49 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-16 3:49 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andi Kleen, Andrew Morton, LKML, linux-mm On Thu, Apr 16, 2009 at 10:26:51AM +0800, KOSAKI Motohiro wrote: > tatus: RO > Content-Length: 13245 > Lines: 380 > > Hi > > > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > > > Export the following page flags in /proc/kpageflags, > > > > > > > just in case they will be useful to someone: > > > > > > > > > > > > > > - PG_swapcache > > > > > > > - PG_swapbacked > > > > > > > - PG_mappedtodisk > > > > > > > - PG_reserved > > > > > > PG_reserved should be exported as PG_KERNEL or somesuch. > > > > PG_KERNEL could be misleading. PG_reserved obviously do not cover all > > (or most) kernel pages. So I'd prefer to export PG_reserved as it is. > > > > It seems that the vast amount of free pages are marked PG_reserved: > > Can I review the document at first? > if no good document for administrator, I can't ack exposing PG_reserved. btw, is this the expected behavior to mark so many free pages as PG_reserved? Last time I looked at it, in 2.6.27, the free pages simply don't have any flags set. //Or maybe it's a false reporting of my tool. Will double check. > > # uname -a > > Linux hp 2.6.30-rc2 #157 SMP Wed Apr 15 19:37:49 CST 2009 x86_64 GNU/Linux > > # echo 1 > /proc/sys/vm/drop_caches > > # ./page-types > > flags page-count MB symbolic-flags long-symbolic-flags > > 0x004000 497474 1943 ______________r_____ reserved > > 0x008000 4454 17 _______________o____ compound > > 0x008014 5 0 __R_D__________o____ referenced,dirty,compound > > 0x000020 1 0 _____l______________ lru > > 0x000028 310 1 ___U_l______________ uptodate,lru > > 0x00002c 18 0 __RU_l______________ referenced,uptodate,lru > > 0x000068 80 0 ___U_lA_____________ uptodate,lru,active > > 0x00006c 157 0 __RU_lA_____________ referenced,uptodate,lru,active > > 0x002078 1 0 ___UDlA______b______ uptodate,dirty,lru,active,swapbacked > > 0x00207c 17 0 __RUDlA______b______ referenced,uptodate,dirty,lru,active,swapbacked > > 0x000228 13 0 ___U_l___x__________ uptodate,lru,reclaim > > 0x000400 2085 8 __________B_________ buddy > > "freed" is better? > buddy is implementation technique name. Not compellingly better :-) I'd expect BUDDY to be a well recognized technique, something close to LRU. PG_BUDDY could be documented as: this page is owned by the buddy system, which manages free memory. PG_FREED may seem more newbie friendly, but there will be the classical newbie question: "Why so few freed pages?!" ;-) It's not likely that an administrator not understanding BUDDY will understand many of the other exported page flags. He will have to query the document anyway. And exporting PG_buddy as it is could be the best option for proficient users. > > 0x000804 1 0 __R________m________ referenced,mmap > > 0x002808 10 0 ___U_______m_b______ uptodate,mmap,swapbacked > > 0x000828 1060 4 ___U_l_____m________ uptodate,lru,mmap > > 0x00082c 215 0 __RU_l_____m________ referenced,uptodate,lru,mmap > > 0x000868 189 0 ___U_lA____m________ uptodate,lru,active,mmap > > 0x002868 4187 16 ___U_lA____m_b______ uptodate,lru,active,mmap,swapbacked > > 0x00286c 30 0 __RU_lA____m_b______ referenced,uptodate,lru,active,mmap,swapbacked > > 0x00086c 1012 3 __RU_lA____m________ referenced,uptodate,lru,active,mmap > > 0x002878 3 0 ___UDlA____m_b______ uptodate,dirty,lru,active,mmap,swapbacked > > 0x008880 936 3 _______S___m___o____ slab,mmap,compound > > 0x000880 1602 6 _______S___m________ slab,mmap > > please don't display mmap and coumpound. it expose SLUB implentation detail. > IOW, if slab flag on, please ignore following flags and mapcount. > - PG_active > - PG_error > - PG_private > - PG_compound > > BTW, if the page don't have PG_lru, following member and flags can be used another meanings. > - PG_active > - PG_referenced > - page::_mapcount > - PG_swapbacked > - PG_reclaim > - PG_unevictable > - PG_mlocked > > and, if the page never interact IO layer, following flags can be used another meanings. > - PG_uptodate > - PG_dirty Good point. I also noticed many of these conditional flags. The perceived solution would be to do some filtering if !CONFIG_DEBUG_KERNEL, to not confuse too many administrators. For kernel developers we want to be faithful :-) > > > 0x0088c0 59 0 ______AS___m___o____ active,slab,mmap,compound > > 0x0008c0 49 0 ______AS___m________ active,slab,mmap > > total 513968 2007 > > > And, PageAnon() result seems provide good information if the page stay in lru. Good point! Will add this bit. > > # ./page-areas 0x004000 > > offset len KB > > 0 15 60KB > > 31 4 16KB > > 159 97 388KB > > 4096 2213 8852KB > > 6899 2385 9540KB > > 9497 3 12KB > > 9728 14528 58112KB > > > > > > > > > - PG_private > > > > > > > - PG_private_2 > > > > > > > - PG_owner_priv_1 > > > > > > > > > > > > > > - PG_head > > > > > > > - PG_tail > > > > > > > - PG_compound > > > > > > I would combine these three into a pseudo "large page" flag. > > > > Very neat idea! Patch updated accordingly. > > > > However - one pity I observed: > > > > # ./page-areas 0x008000 > > offset len KB > > 3088 4 16KB > > > > We can no longer tell if the above line means one 4-page hugepage, or two > > 2-page hugepages... Adding PG_COMPOUND_TAIL into the CONFIG_DEBUG_KERNEL block > > can help kernel developers. Or will it be ever cared by administrators? > > > > 341196 2 8KB > > 341202 2 8KB > > 341262 2 8KB > > 341272 8 32KB > > 341296 8 32KB > > 488448 24 96KB > > 488490 2 8KB > > 488496 320 1280KB > > 488842 2 8KB > > 488848 40 160KB > > > > > > > > > > > > > > > > - PG_unevictable > > > > > > > - PG_mlocked > > > > > > > > > > > > > > - PG_poison > > > > > > PG_poison is also useful to export. But since it depends on my > > > patchkit I will pull a patch for that into the HWPOISON series. > > > > That's not a problem - since the PG_poison line is be protected by > > #ifdef CONFIG_MEMORY_FAILURE :-) > > > > > > > > > - PG_unevictable > > > > > > > - PG_mlocked > > > > > > > > this 9 flags shouldn't exported. > > > > I can't imazine administrator use what purpose those flags. > > > > > > I think an abstraced "PG_pinned" or somesuch flag that combines > > > page lock, unevictable, mlocked would be useful for the administrator. > > > > The PG_PINNED abstraction risks hiding useful information. > > The administrator may not only care about the pinned pages, > > but also care _why_ they are pinned, i.e. ramfs.. or mlock? > > > > So it might be good to export them as is, with proper document. > > > > Here is the v2 patch, with flags for kernel hackers numbered from 32. > > Comments are welcome! > > if you can write good document, PG_unevictable is exportable. > but PG_mlock isn't. > > that's implementation tecknique of efficient unevictable pages for mlock. > we can change the future. Yup. That's in line with my vague feeling. For PG_unevictable we can say that the page is owned by the unevictable (non-)lru and not a candidate for LRU page reclaims. But for PG_mlock it's more about an assistant for kernel optimizations and there are no guarantees... Thanks, Fengguang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-16 3:49 ` Wu Fengguang @ 2009-04-16 6:30 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-16 6:30 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andi Kleen, Andrew Morton, LKML, linux-mm On Thu, Apr 16, 2009 at 11:49:18AM +0800, Wu Fengguang wrote: > On Thu, Apr 16, 2009 at 10:26:51AM +0800, KOSAKI Motohiro wrote: > > tatus: RO > > Content-Length: 13245 > > Lines: 380 > > > > Hi > > > > > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > > > > Export the following page flags in /proc/kpageflags, > > > > > > > > just in case they will be useful to someone: > > > > > > > > > > > > > > > > - PG_swapcache > > > > > > > > - PG_swapbacked > > > > > > > > - PG_mappedtodisk > > > > > > > > - PG_reserved > > > > > > > > PG_reserved should be exported as PG_KERNEL or somesuch. > > > > > > PG_KERNEL could be misleading. PG_reserved obviously do not cover all > > > (or most) kernel pages. So I'd prefer to export PG_reserved as it is. > > > > > > It seems that the vast amount of free pages are marked PG_reserved: > > > > Can I review the document at first? > > if no good document for administrator, I can't ack exposing PG_reserved. > > btw, is this the expected behavior to mark so many free pages as PG_reserved? > Last time I looked at it, in 2.6.27, the free pages simply don't have > any flags set. > > //Or maybe it's a false reporting of my tool. Will double check. Ah it's my fault. Something goes wrong when I convert the page-types data structure from a huge array to hash table. Here is the correct output: # echo 1 > /proc/sys/vm/drop_caches # ./page-types flags page-count MB symbolic-flags long-symbolic-flags 0x000000000000 479149 1871 ___________________________ 0x000000004000 19258 75 ______________r____________ reserved 0x000000008000 16 0 _______________o___________ compound 0x004000008000 3655 14 _______________o__________T compound,compound_tail 0x000000008014 1 0 __R_D__________o___________ referenced,dirty,compound 0x004000008014 4 0 __R_D__________o__________T referenced,dirty,compound,compound_tail 0x000000000020 1 0 _____l_____________________ lru 0x000000000028 58 0 ___U_l_____________________ uptodate,lru 0x00000000203c 17 0 __RUDl_______b_____________ referenced,uptodate,dirty,lru,swapbacked 0x000200000064 20 0 __R__lA______________P_____ referenced,lru,active,private 0x000200000068 5 0 ___U_lA______________P_____ uptodate,lru,active,private 0x00000000006c 17 0 __RU_lA____________________ referenced,uptodate,lru,active 0x00020000006c 2 0 __RU_lA______________P_____ referenced,uptodate,lru,active,private 0x000000002078 1 0 ___UDlA______b_____________ uptodate,dirty,lru,active,swapbacked 0x000000000228 1 0 ___U_l___x_________________ uptodate,lru,reclaim 0x000000000400 3600 14 __________B________________ buddy 0x000000000804 1 0 __R________m_______________ referenced,mmap 0x000000002808 6 0 ___U_______m_b_____________ uptodate,mmap,swapbacked 0x000000002828 974 3 ___U_l_____m_b_____________ uptodate,lru,mmap,swapbacked 0x00000000082c 1 0 __RU_l_____m_______________ referenced,uptodate,lru,mmap 0x000000000868 1501 5 ___U_lA____m_______________ uptodate,lru,active,mmap 0x000000002868 2696 10 ___U_lA____m_b_____________ uptodate,lru,active,mmap,swapbacked 0x00000000086c 969 3 __RU_lA____m_______________ referenced,uptodate,lru,active,mmap 0x00000000286c 17 0 __RU_lA____m_b_____________ referenced,uptodate,lru,active,mmap,swapbacked 0x000000002878 2 0 ___UDlA____m_b_____________ uptodate,dirty,lru,active,mmap,swapbacked 0x000000008880 694 2 _______S___m___o___________ slab,mmap,compound 0x000000000880 1183 4 _______S___m_______________ slab,mmap 0x0000000088c0 62 0 ______AS___m___o___________ active,slab,mmap,compound 0x0000000008c0 57 0 ______AS___m_______________ active,slab,mmap total 513968 2007 Thanks, Fengguang ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-16 6:30 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-16 6:30 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andi Kleen, Andrew Morton, LKML, linux-mm On Thu, Apr 16, 2009 at 11:49:18AM +0800, Wu Fengguang wrote: > On Thu, Apr 16, 2009 at 10:26:51AM +0800, KOSAKI Motohiro wrote: > > tatus: RO > > Content-Length: 13245 > > Lines: 380 > > > > Hi > > > > > > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > > > > > Export the following page flags in /proc/kpageflags, > > > > > > > > just in case they will be useful to someone: > > > > > > > > > > > > > > > > - PG_swapcache > > > > > > > > - PG_swapbacked > > > > > > > > - PG_mappedtodisk > > > > > > > > - PG_reserved > > > > > > > > PG_reserved should be exported as PG_KERNEL or somesuch. > > > > > > PG_KERNEL could be misleading. PG_reserved obviously do not cover all > > > (or most) kernel pages. So I'd prefer to export PG_reserved as it is. > > > > > > It seems that the vast amount of free pages are marked PG_reserved: > > > > Can I review the document at first? > > if no good document for administrator, I can't ack exposing PG_reserved. > > btw, is this the expected behavior to mark so many free pages as PG_reserved? > Last time I looked at it, in 2.6.27, the free pages simply don't have > any flags set. > > //Or maybe it's a false reporting of my tool. Will double check. Ah it's my fault. Something goes wrong when I convert the page-types data structure from a huge array to hash table. Here is the correct output: # echo 1 > /proc/sys/vm/drop_caches # ./page-types flags page-count MB symbolic-flags long-symbolic-flags 0x000000000000 479149 1871 ___________________________ 0x000000004000 19258 75 ______________r____________ reserved 0x000000008000 16 0 _______________o___________ compound 0x004000008000 3655 14 _______________o__________T compound,compound_tail 0x000000008014 1 0 __R_D__________o___________ referenced,dirty,compound 0x004000008014 4 0 __R_D__________o__________T referenced,dirty,compound,compound_tail 0x000000000020 1 0 _____l_____________________ lru 0x000000000028 58 0 ___U_l_____________________ uptodate,lru 0x00000000203c 17 0 __RUDl_______b_____________ referenced,uptodate,dirty,lru,swapbacked 0x000200000064 20 0 __R__lA______________P_____ referenced,lru,active,private 0x000200000068 5 0 ___U_lA______________P_____ uptodate,lru,active,private 0x00000000006c 17 0 __RU_lA____________________ referenced,uptodate,lru,active 0x00020000006c 2 0 __RU_lA______________P_____ referenced,uptodate,lru,active,private 0x000000002078 1 0 ___UDlA______b_____________ uptodate,dirty,lru,active,swapbacked 0x000000000228 1 0 ___U_l___x_________________ uptodate,lru,reclaim 0x000000000400 3600 14 __________B________________ buddy 0x000000000804 1 0 __R________m_______________ referenced,mmap 0x000000002808 6 0 ___U_______m_b_____________ uptodate,mmap,swapbacked 0x000000002828 974 3 ___U_l_____m_b_____________ uptodate,lru,mmap,swapbacked 0x00000000082c 1 0 __RU_l_____m_______________ referenced,uptodate,lru,mmap 0x000000000868 1501 5 ___U_lA____m_______________ uptodate,lru,active,mmap 0x000000002868 2696 10 ___U_lA____m_b_____________ uptodate,lru,active,mmap,swapbacked 0x00000000086c 969 3 __RU_lA____m_______________ referenced,uptodate,lru,active,mmap 0x00000000286c 17 0 __RU_lA____m_b_____________ referenced,uptodate,lru,active,mmap,swapbacked 0x000000002878 2 0 ___UDlA____m_b_____________ uptodate,dirty,lru,active,mmap,swapbacked 0x000000008880 694 2 _______S___m___o___________ slab,mmap,compound 0x000000000880 1183 4 _______S___m_______________ slab,mmap 0x0000000088c0 62 0 ______AS___m___o___________ active,slab,mmap,compound 0x0000000008c0 57 0 ______AS___m_______________ active,slab,mmap total 513968 2007 Thanks, Fengguang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) 2009-04-16 2:26 ` KOSAKI Motohiro @ 2009-04-23 2:26 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-23 2:26 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andi Kleen, Andrew Morton, LKML, linux-mm Andi and KOSAKI: can we hopefully reach harmony of opinions on this version? Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers. 1) for kernel hackers (on CONFIG_DEBUG_KERNEL) - all available page flags are exported, and - exported as is 2) for admins and end users - only the more `well known' flags are exported: 11. KPF_MMAP (pseudo flag) memory mapped page 12. KPF_ANON (pseudo flag) memory mapped page (anonymous) 13. KPF_SWAPCACHE page is in swap cache 14. KPF_SWAPBACKED page is swap/RAM backed 15. KPF_COMPOUND_HEAD (*) 16. KPF_COMPOUND_TAIL (*) 17. KPF_UNEVICTABLE page is in the unevictable LRU list 18. KPF_POISON hardware detected corruption 19. KPF_NOPAGE (pseudo flag) no page frame at the address (*) For compound pages, exporting _both_ head/tail info enables users to tell where a compound page starts/ends, and its order. - limit flags to their typical usage scenario, as indicated by KOSAKI: - LRU pages: only export relevant flags - PG_lru - PG_unevictable - PG_active - PG_referenced - page_mapped() - PageAnon() - PG_swapcache - PG_swapbacked - PG_reclaim - no-IO pages: mask out irrelevant flags - PG_dirty - PG_uptodate - PG_writeback - SLAB pages: mask out overloaded flags: - PG_error - PG_active - PG_private - PG_reclaim: filter out the overloaded PG_readahead Note that compound page flags are exported faithfully to end user. This risks exposing internal implementation details of the SLUB allocator, however hiding it risks larger impacts: - admins may wonder where all the compound pages gone - the use of compound pages in SLUB might have some real world relevance, so that end users want to be aware of this behavior - admins may be confused on inconsistent number of head/tail segments This is because SLUB only marks PG_slab on the compound head page. If we mask out PG_head|PG_tail for PG_slab pages, we are actually only masking out PG_head flags. Therefore the PG_tail segments will outnumber PG_head ones, which puzzled me for some time.. Here are the admin/linus views of all page flags on a newly booted nfs-root system: # ./page-types # for admin flags page-count MB symbolic-flags long-symbolic-flags 0x000000000000 491449 1919 ____________________________ 0x000000008000 15 0 _______________H____________ compound_head 0x000000010000 4280 16 ________________T___________ compound_tail 0x000000000008 17 0 ___U________________________ uptodate 0x000000008010 1 0 ____D__________H____________ dirty,compound_head 0x000000010010 4 0 ____D___________T___________ dirty,compound_tail 0x000000000020 1 0 _____l______________________ lru 0x000000000028 2678 10 ___U_l______________________ uptodate,lru 0x00000000002c 5244 20 __RU_l______________________ referenced,uptodate,lru 0x000000004060 1 0 _____lA_______b_____________ lru,active,swapbacked 0x000000004064 13 0 __R__lA_______b_____________ referenced,lru,active,swapbacked 0x000000000068 236 0 ___U_lA_____________________ uptodate,lru,active 0x00000000006c 927 3 __RU_lA_____________________ referenced,uptodate,lru,active 0x000000008080 968 3 _______S_______H____________ slab,compound_head 0x000000000080 1539 6 _______S____________________ slab 0x000000000400 516 2 __________B_________________ buddy 0x000000000828 1142 4 ___U_l_____M________________ uptodate,lru,mmap 0x00000000082c 280 1 __RU_l_____M________________ referenced,uptodate,lru,mmap 0x000000004860 2 0 _____lA____M__b_____________ lru,active,mmap,swapbacked 0x000000000868 366 1 ___U_lA____M________________ uptodate,lru,active,mmap 0x00000000086c 623 2 __RU_lA____M________________ referenced,uptodate,lru,active,mmap 0x000000005868 3639 14 ___U_lA____Ma_b_____________ uptodate,lru,active,mmap,anonymous,swapbacked 0x00000000586c 27 0 __RU_lA____Ma_b_____________ referenced,uptodate,lru,active,mmap,anonymous,swapbacked total 513968 2007 # ./page-types # for linus, when CONFIG_DEBUG_KERNEL is turned on flags page-count MB symbolic-flags long-symbolic-flags 0x000000000000 471731 1842 ____________________________ 0x000100000000 19258 75 ____________________r_______ reserved 0x000000008000 15 0 _______________H____________ compound_head 0x000000010000 4270 16 ________________T___________ compound_tail 0x000000000008 3 0 ___U________________________ uptodate 0x000000008014 1 0 __R_D__________H____________ referenced,dirty,compound_head 0x000000010014 4 0 __R_D___________T___________ referenced,dirty,compound_tail 0x000000000020 1 0 _____l______________________ lru 0x000000000028 2626 10 ___U_l______________________ uptodate,lru 0x00000000002c 5244 20 __RU_l______________________ referenced,uptodate,lru 0x000000000068 238 0 ___U_lA_____________________ uptodate,lru,active 0x00000000006c 925 3 __RU_lA_____________________ referenced,uptodate,lru,active 0x000000004078 1 0 ___UDlA_______b_____________ uptodate,dirty,lru,active,swapbacked 0x00000000407c 13 0 __RUDlA_______b_____________ referenced,uptodate,dirty,lru,active,swapbacked 0x000000000228 49 0 ___U_l___I__________________ uptodate,lru,reclaim 0x000000000400 523 2 __________B_________________ buddy 0x000000000804 1 0 __R________M________________ referenced,mmap 0x00000000080c 1 0 __RU_______M________________ referenced,uptodate,mmap 0x000000000828 1142 4 ___U_l_____M________________ uptodate,lru,mmap 0x00000000082c 280 1 __RU_l_____M________________ referenced,uptodate,lru,mmap 0x000000000868 366 1 ___U_lA____M________________ uptodate,lru,active,mmap 0x00000000086c 622 2 __RU_lA____M________________ referenced,uptodate,lru,active,mmap 0x000000004878 2 0 ___UDlA____M__b_____________ uptodate,dirty,lru,active,mmap,swapbacked 0x000000008880 907 3 _______S___M___H____________ slab,mmap,compound_head 0x000000000880 1488 5 _______S___M________________ slab,mmap 0x0000000088c0 59 0 ______AS___M___H____________ active,slab,mmap,compound_head 0x0000000008c0 49 0 ______AS___M________________ active,slab,mmap 0x000000001000 465 1 ____________a_______________ anonymous 0x000000005008 8 0 ___U________a_b_____________ uptodate,anonymous,swapbacked 0x000000005808 4 0 ___U_______Ma_b_____________ uptodate,mmap,anonymous,swapbacked 0x00000000580c 1 0 __RU_______Ma_b_____________ referenced,uptodate,mmap,anonymous,swapbacked 0x000000005868 3645 14 ___U_lA____Ma_b_____________ uptodate,lru,active,mmap,anonymous,swapbacked 0x00000000586c 26 0 __RU_lA____Ma_b_____________ referenced,uptodate,lru,active,mmap,anonymous,swapbacked total 513968 2007 Kudos to KOSAKI and Andi for the extensive recommendations! Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Matt Mackall <mpm@selenic.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> --- Documentation/vm/pagemap.txt | 65 ++++++++++ fs/proc/page.c | 197 +++++++++++++++++++++++++++------ 2 files changed, 227 insertions(+), 35 deletions(-) --- mm.orig/fs/proc/page.c +++ mm/fs/proc/page.c @@ -6,6 +6,7 @@ #include <linux/mmzone.h> #include <linux/proc_fs.h> #include <linux/seq_file.h> +#include <linux/backing-dev.h> #include <asm/uaccess.h> #include "internal.h" @@ -68,19 +69,167 @@ static const struct file_operations proc /* These macros are used to decouple internal flags from exported ones */ -#define KPF_LOCKED 0 -#define KPF_ERROR 1 -#define KPF_REFERENCED 2 -#define KPF_UPTODATE 3 -#define KPF_DIRTY 4 -#define KPF_LRU 5 -#define KPF_ACTIVE 6 -#define KPF_SLAB 7 -#define KPF_WRITEBACK 8 -#define KPF_RECLAIM 9 -#define KPF_BUDDY 10 +#define KPF_LOCKED 0 +#define KPF_ERROR 1 +#define KPF_REFERENCED 2 +#define KPF_UPTODATE 3 +#define KPF_DIRTY 4 +#define KPF_LRU 5 +#define KPF_ACTIVE 6 +#define KPF_SLAB 7 +#define KPF_WRITEBACK 8 +#define KPF_RECLAIM 9 +#define KPF_BUDDY 10 + +/* new additions in 2.6.31 */ +#define KPF_MMAP 11 +#define KPF_ANON 12 +#define KPF_SWAPCACHE 13 +#define KPF_SWAPBACKED 14 +#define KPF_COMPOUND_HEAD 15 +#define KPF_COMPOUND_TAIL 16 +#define KPF_UNEVICTABLE 17 +#define KPF_POISON 18 +#define KPF_NOPAGE 19 + +/* kernel hacking assistances */ +#define KPF_RESERVED 32 +#define KPF_MLOCKED 33 +#define KPF_MAPPEDTODISK 34 +#define KPF_PRIVATE 35 +#define KPF_PRIVATE2 36 +#define KPF_OWNER_PRIVATE 37 +#define KPF_ARCH 38 +#define KPF_UNCACHED 39 + +/* + * Kernel flags are exported faithfully to Linus and his fellow hackers. + * Otherwise some details are masked to avoid confusing the end user: + * - some kernel flags are completely invisible + * - some kernel flags are conditionally invisible on their odd usages + */ +#ifdef CONFIG_DEBUG_KERNEL +static inline int genuine_linus(void) { return 1; } +#else +static inline int genuine_linus(void) { return 0; } +#endif + +#define kpf_copy_bit(uflags, kflags, visible, ubit, kbit) \ + do { \ + if (visible || genuine_linus()) \ + uflags |= ((kflags >> kbit) & 1) << ubit; \ + } while (0); + +/* a helper function _not_ intended for more general uses */ +static inline int page_cap_writeback_dirty(struct page *page) +{ + struct address_space *mapping = NULL; + + if (!PageSlab(page)) + mapping = page_mapping(page); + + return !mapping || mapping_cap_writeback_dirty(mapping); +} -#define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) +static u64 get_uflags(struct page *page) +{ + u64 k; + u64 u; + int io; + int lru; + int slab; + + /* + * pseudo flag: KPF_NOPAGE + * it differentiates a memory hole from a page with no flags + */ + if (!page) + return 1 << KPF_NOPAGE; + + k = page->flags; + u = 0; + + io = page_cap_writeback_dirty(page); + lru = k & (1 << PG_lru); + slab = k & (1 << PG_slab); + + /* + * pseudo flags for the well known (anonymous) memory mapped pages + */ + if (lru || genuine_linus()) { + if (page_mapped(page)) + u |= 1 << KPF_MMAP; + if (PageAnon(page)) + u |= 1 << KPF_ANON; + } + + /* + * compound pages: export both head/tail info + * they together define a compound page's start/end pos and order + */ + if (PageHead(page)) + u |= 1 << KPF_COMPOUND_HEAD; + if (PageTail(page)) + u |= 1 << KPF_COMPOUND_TAIL; + + kpf_copy_bit(u, k, 1, KPF_LOCKED, PG_locked); + + kpf_copy_bit(u, k, 1, KPF_SLAB, PG_slab); + kpf_copy_bit(u, k, 1, KPF_BUDDY, PG_buddy); + + kpf_copy_bit(u, k, io, KPF_ERROR, PG_error); + kpf_copy_bit(u, k, io, KPF_DIRTY, PG_dirty); + kpf_copy_bit(u, k, io, KPF_UPTODATE, PG_uptodate); + kpf_copy_bit(u, k, io, KPF_WRITEBACK, PG_writeback); + + kpf_copy_bit(u, k, 1, KPF_LRU, PG_lru); + kpf_copy_bit(u, k, lru, KPF_REFERENCED, PG_referenced); + kpf_copy_bit(u, k, lru, KPF_ACTIVE, PG_active); + kpf_copy_bit(u, k, lru, KPF_RECLAIM, PG_reclaim); + + kpf_copy_bit(u, k, lru, KPF_SWAPCACHE, PG_swapcache); + kpf_copy_bit(u, k, lru, KPF_SWAPBACKED, PG_swapbacked); + +#ifdef CONFIG_MEMORY_FAILURE + kpf_copy_bit(u, k, 1, KPF_POISON, PG_poison); +#endif + +#ifdef CONFIG_UNEVICTABLE_LRU + kpf_copy_bit(u, k, lru, KPF_UNEVICTABLE, PG_unevictable); + kpf_copy_bit(u, k, 0, KPF_MLOCKED, PG_mlocked); +#endif + + kpf_copy_bit(u, k, 0, KPF_RESERVED, PG_reserved); + kpf_copy_bit(u, k, 0, KPF_MAPPEDTODISK, PG_mappedtodisk); + kpf_copy_bit(u, k, 0, KPF_PRIVATE, PG_private); + kpf_copy_bit(u, k, 0, KPF_PRIVATE2, PG_private_2); + kpf_copy_bit(u, k, 0, KPF_OWNER_PRIVATE, PG_owner_priv_1); + kpf_copy_bit(u, k, 0, KPF_ARCH, PG_arch_1); + +#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR + kpf_copy_bit(u, k, 0, KPF_UNCACHED, PG_uncached); +#endif + + if (!genuine_linus()) { + /* + * SLAB/SLOB/SLUB overload some page flags which may confuse end user + */ + if (slab) { + u &= ~ ((1 << KPF_ACTIVE) | + (1 << KPF_ERROR) | + (1 << KPF_MMAP)); + } + /* + * PG_reclaim could be overloaded as PG_readahead, + * and we only want to export the first one. + */ + if ((u & ((1 << KPF_RECLAIM) | (1 << KPF_WRITEBACK))) == + (1 << KPF_RECLAIM)) + u &= ~ (1 << KPF_RECLAIM); + } + + return u; +}; static ssize_t kpageflags_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) @@ -90,7 +239,6 @@ static ssize_t kpageflags_read(struct fi unsigned long src = *ppos; unsigned long pfn; ssize_t ret = 0; - u64 kflags, uflags; pfn = src / KPMSIZE; count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); @@ -98,32 +246,17 @@ static ssize_t kpageflags_read(struct fi return -EINVAL; while (count > 0) { - ppage = NULL; if (pfn_valid(pfn)) ppage = pfn_to_page(pfn); - pfn++; - if (!ppage) - kflags = 0; else - kflags = ppage->flags; - - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); + ppage = NULL; - if (put_user(uflags, out++)) { + if (put_user(get_uflags(ppage), out)) { ret = -EFAULT; break; } - + out++; + pfn++; count -= KPMSIZE; } --- mm.orig/Documentation/vm/pagemap.txt +++ mm/Documentation/vm/pagemap.txt @@ -12,9 +12,9 @@ There are three components to pagemap: value for each virtual page, containing the following data (from fs/proc/task_mmu.c, above pagemap_read): - * Bits 0-55 page frame number (PFN) if present + * Bits 0-54 page frame number (PFN) if present * Bits 0-4 swap type if swapped - * Bits 5-55 swap offset if swapped + * Bits 5-54 swap offset if swapped * Bits 55-60 page shift (page size = 1<<page shift) * Bit 61 reserved for future use * Bit 62 page swapped @@ -36,7 +36,7 @@ There are three components to pagemap: * /proc/kpageflags. This file contains a 64-bit set of flags for each page, indexed by PFN. - The flags are (from fs/proc/proc_misc, above kpageflags_read): + The flags are (from fs/proc/page.c, above kpageflags_read): 0. LOCKED 1. ERROR @@ -49,6 +49,65 @@ There are three components to pagemap: 8. WRITEBACK 9. RECLAIM 10. BUDDY + 11. MMAP + 12. ANON + 13. SWAPCACHE + 14. SWAPBACKED + 15. COMPOUND_HEAD + 16. COMPOUND_TAIL + 17. UNEVICTABLE + 18. POISON + 19. NOPAGE + +Short descriptions to the page flags: + + 0. LOCKED + page is being locked for exclusive access, eg. by undergoing read/write IO + + 7. SLAB + page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator + +10. BUDDY + a free memory block managed by the buddy system allocator + The buddy system organizes free memory in blocks of various orders. + An order N block has 2^N physically contiguous pages, with the BUDDY flag + set for and _only_ for the first page. + +15. COMPOUND_HEAD +16. COMPOUND_TAIL + A compound page with order N consists of 2^N physically contiguous pages. + A compound page with order 2 takes the form of "HTTT", where H donates its + head page and T donates its tail page(s). The major consumers of compound + pages are hugeTLB pages (Documentation/vm/hugetlbpage.txt), the SLUB etc. + memory allocators and various device drivers. + +18. POISON + hardware has detected memory corruption on this page + +19. NOPAGE + no page frame exists at the requested address + + [IO related page flags] + 1. ERROR IO error occurred + 3. UPTODATE page has up-to-date data + ie. for file backed page: (in-memory data revision >= on-disk one) + 4. DIRTY page has been written to, hence contains new data + ie. for file backed page: (in-memory data revision > on-disk one) + 8. WRITEBACK page is being synced to disk + + [LRU related page flags] + 5. LRU page is in one of the LRU lists + 6. ACTIVE page is in the active LRU list +17. UNEVICTABLE page is in the unevictable (non-)LRU list + It is somehow pinned and not a candidate for LRU page reclaims, + eg. ramfs pages, shmctl(SHM_LOCK) and mlock() memory segments + 2. REFERENCED page has been referenced since last LRU list enqueue/requeue + 9. RECLAIM page will be reclaimed soon after its pageout IO completed +11. MMAP a memory mapped page +12. ANON a memory mapped page who is not a file page +13. SWAPCACHE page is mapped to swap space, ie. has an associated swap entry +14. SWAPBACKED page is backed by swap/RAM + Using pagemap to do something useful: ^ permalink raw reply [flat|nested] 44+ messages in thread
* [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) @ 2009-04-23 2:26 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-23 2:26 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andi Kleen, Andrew Morton, LKML, linux-mm Andi and KOSAKI: can we hopefully reach harmony of opinions on this version? Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers. 1) for kernel hackers (on CONFIG_DEBUG_KERNEL) - all available page flags are exported, and - exported as is 2) for admins and end users - only the more `well known' flags are exported: 11. KPF_MMAP (pseudo flag) memory mapped page 12. KPF_ANON (pseudo flag) memory mapped page (anonymous) 13. KPF_SWAPCACHE page is in swap cache 14. KPF_SWAPBACKED page is swap/RAM backed 15. KPF_COMPOUND_HEAD (*) 16. KPF_COMPOUND_TAIL (*) 17. KPF_UNEVICTABLE page is in the unevictable LRU list 18. KPF_POISON hardware detected corruption 19. KPF_NOPAGE (pseudo flag) no page frame at the address (*) For compound pages, exporting _both_ head/tail info enables users to tell where a compound page starts/ends, and its order. - limit flags to their typical usage scenario, as indicated by KOSAKI: - LRU pages: only export relevant flags - PG_lru - PG_unevictable - PG_active - PG_referenced - page_mapped() - PageAnon() - PG_swapcache - PG_swapbacked - PG_reclaim - no-IO pages: mask out irrelevant flags - PG_dirty - PG_uptodate - PG_writeback - SLAB pages: mask out overloaded flags: - PG_error - PG_active - PG_private - PG_reclaim: filter out the overloaded PG_readahead Note that compound page flags are exported faithfully to end user. This risks exposing internal implementation details of the SLUB allocator, however hiding it risks larger impacts: - admins may wonder where all the compound pages gone - the use of compound pages in SLUB might have some real world relevance, so that end users want to be aware of this behavior - admins may be confused on inconsistent number of head/tail segments This is because SLUB only marks PG_slab on the compound head page. If we mask out PG_head|PG_tail for PG_slab pages, we are actually only masking out PG_head flags. Therefore the PG_tail segments will outnumber PG_head ones, which puzzled me for some time.. Here are the admin/linus views of all page flags on a newly booted nfs-root system: # ./page-types # for admin flags page-count MB symbolic-flags long-symbolic-flags 0x000000000000 491449 1919 ____________________________ 0x000000008000 15 0 _______________H____________ compound_head 0x000000010000 4280 16 ________________T___________ compound_tail 0x000000000008 17 0 ___U________________________ uptodate 0x000000008010 1 0 ____D__________H____________ dirty,compound_head 0x000000010010 4 0 ____D___________T___________ dirty,compound_tail 0x000000000020 1 0 _____l______________________ lru 0x000000000028 2678 10 ___U_l______________________ uptodate,lru 0x00000000002c 5244 20 __RU_l______________________ referenced,uptodate,lru 0x000000004060 1 0 _____lA_______b_____________ lru,active,swapbacked 0x000000004064 13 0 __R__lA_______b_____________ referenced,lru,active,swapbacked 0x000000000068 236 0 ___U_lA_____________________ uptodate,lru,active 0x00000000006c 927 3 __RU_lA_____________________ referenced,uptodate,lru,active 0x000000008080 968 3 _______S_______H____________ slab,compound_head 0x000000000080 1539 6 _______S____________________ slab 0x000000000400 516 2 __________B_________________ buddy 0x000000000828 1142 4 ___U_l_____M________________ uptodate,lru,mmap 0x00000000082c 280 1 __RU_l_____M________________ referenced,uptodate,lru,mmap 0x000000004860 2 0 _____lA____M__b_____________ lru,active,mmap,swapbacked 0x000000000868 366 1 ___U_lA____M________________ uptodate,lru,active,mmap 0x00000000086c 623 2 __RU_lA____M________________ referenced,uptodate,lru,active,mmap 0x000000005868 3639 14 ___U_lA____Ma_b_____________ uptodate,lru,active,mmap,anonymous,swapbacked 0x00000000586c 27 0 __RU_lA____Ma_b_____________ referenced,uptodate,lru,active,mmap,anonymous,swapbacked total 513968 2007 # ./page-types # for linus, when CONFIG_DEBUG_KERNEL is turned on flags page-count MB symbolic-flags long-symbolic-flags 0x000000000000 471731 1842 ____________________________ 0x000100000000 19258 75 ____________________r_______ reserved 0x000000008000 15 0 _______________H____________ compound_head 0x000000010000 4270 16 ________________T___________ compound_tail 0x000000000008 3 0 ___U________________________ uptodate 0x000000008014 1 0 __R_D__________H____________ referenced,dirty,compound_head 0x000000010014 4 0 __R_D___________T___________ referenced,dirty,compound_tail 0x000000000020 1 0 _____l______________________ lru 0x000000000028 2626 10 ___U_l______________________ uptodate,lru 0x00000000002c 5244 20 __RU_l______________________ referenced,uptodate,lru 0x000000000068 238 0 ___U_lA_____________________ uptodate,lru,active 0x00000000006c 925 3 __RU_lA_____________________ referenced,uptodate,lru,active 0x000000004078 1 0 ___UDlA_______b_____________ uptodate,dirty,lru,active,swapbacked 0x00000000407c 13 0 __RUDlA_______b_____________ referenced,uptodate,dirty,lru,active,swapbacked 0x000000000228 49 0 ___U_l___I__________________ uptodate,lru,reclaim 0x000000000400 523 2 __________B_________________ buddy 0x000000000804 1 0 __R________M________________ referenced,mmap 0x00000000080c 1 0 __RU_______M________________ referenced,uptodate,mmap 0x000000000828 1142 4 ___U_l_____M________________ uptodate,lru,mmap 0x00000000082c 280 1 __RU_l_____M________________ referenced,uptodate,lru,mmap 0x000000000868 366 1 ___U_lA____M________________ uptodate,lru,active,mmap 0x00000000086c 622 2 __RU_lA____M________________ referenced,uptodate,lru,active,mmap 0x000000004878 2 0 ___UDlA____M__b_____________ uptodate,dirty,lru,active,mmap,swapbacked 0x000000008880 907 3 _______S___M___H____________ slab,mmap,compound_head 0x000000000880 1488 5 _______S___M________________ slab,mmap 0x0000000088c0 59 0 ______AS___M___H____________ active,slab,mmap,compound_head 0x0000000008c0 49 0 ______AS___M________________ active,slab,mmap 0x000000001000 465 1 ____________a_______________ anonymous 0x000000005008 8 0 ___U________a_b_____________ uptodate,anonymous,swapbacked 0x000000005808 4 0 ___U_______Ma_b_____________ uptodate,mmap,anonymous,swapbacked 0x00000000580c 1 0 __RU_______Ma_b_____________ referenced,uptodate,mmap,anonymous,swapbacked 0x000000005868 3645 14 ___U_lA____Ma_b_____________ uptodate,lru,active,mmap,anonymous,swapbacked 0x00000000586c 26 0 __RU_lA____Ma_b_____________ referenced,uptodate,lru,active,mmap,anonymous,swapbacked total 513968 2007 Kudos to KOSAKI and Andi for the extensive recommendations! Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Matt Mackall <mpm@selenic.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> --- Documentation/vm/pagemap.txt | 65 ++++++++++ fs/proc/page.c | 197 +++++++++++++++++++++++++++------ 2 files changed, 227 insertions(+), 35 deletions(-) --- mm.orig/fs/proc/page.c +++ mm/fs/proc/page.c @@ -6,6 +6,7 @@ #include <linux/mmzone.h> #include <linux/proc_fs.h> #include <linux/seq_file.h> +#include <linux/backing-dev.h> #include <asm/uaccess.h> #include "internal.h" @@ -68,19 +69,167 @@ static const struct file_operations proc /* These macros are used to decouple internal flags from exported ones */ -#define KPF_LOCKED 0 -#define KPF_ERROR 1 -#define KPF_REFERENCED 2 -#define KPF_UPTODATE 3 -#define KPF_DIRTY 4 -#define KPF_LRU 5 -#define KPF_ACTIVE 6 -#define KPF_SLAB 7 -#define KPF_WRITEBACK 8 -#define KPF_RECLAIM 9 -#define KPF_BUDDY 10 +#define KPF_LOCKED 0 +#define KPF_ERROR 1 +#define KPF_REFERENCED 2 +#define KPF_UPTODATE 3 +#define KPF_DIRTY 4 +#define KPF_LRU 5 +#define KPF_ACTIVE 6 +#define KPF_SLAB 7 +#define KPF_WRITEBACK 8 +#define KPF_RECLAIM 9 +#define KPF_BUDDY 10 + +/* new additions in 2.6.31 */ +#define KPF_MMAP 11 +#define KPF_ANON 12 +#define KPF_SWAPCACHE 13 +#define KPF_SWAPBACKED 14 +#define KPF_COMPOUND_HEAD 15 +#define KPF_COMPOUND_TAIL 16 +#define KPF_UNEVICTABLE 17 +#define KPF_POISON 18 +#define KPF_NOPAGE 19 + +/* kernel hacking assistances */ +#define KPF_RESERVED 32 +#define KPF_MLOCKED 33 +#define KPF_MAPPEDTODISK 34 +#define KPF_PRIVATE 35 +#define KPF_PRIVATE2 36 +#define KPF_OWNER_PRIVATE 37 +#define KPF_ARCH 38 +#define KPF_UNCACHED 39 + +/* + * Kernel flags are exported faithfully to Linus and his fellow hackers. + * Otherwise some details are masked to avoid confusing the end user: + * - some kernel flags are completely invisible + * - some kernel flags are conditionally invisible on their odd usages + */ +#ifdef CONFIG_DEBUG_KERNEL +static inline int genuine_linus(void) { return 1; } +#else +static inline int genuine_linus(void) { return 0; } +#endif + +#define kpf_copy_bit(uflags, kflags, visible, ubit, kbit) \ + do { \ + if (visible || genuine_linus()) \ + uflags |= ((kflags >> kbit) & 1) << ubit; \ + } while (0); + +/* a helper function _not_ intended for more general uses */ +static inline int page_cap_writeback_dirty(struct page *page) +{ + struct address_space *mapping = NULL; + + if (!PageSlab(page)) + mapping = page_mapping(page); + + return !mapping || mapping_cap_writeback_dirty(mapping); +} -#define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) +static u64 get_uflags(struct page *page) +{ + u64 k; + u64 u; + int io; + int lru; + int slab; + + /* + * pseudo flag: KPF_NOPAGE + * it differentiates a memory hole from a page with no flags + */ + if (!page) + return 1 << KPF_NOPAGE; + + k = page->flags; + u = 0; + + io = page_cap_writeback_dirty(page); + lru = k & (1 << PG_lru); + slab = k & (1 << PG_slab); + + /* + * pseudo flags for the well known (anonymous) memory mapped pages + */ + if (lru || genuine_linus()) { + if (page_mapped(page)) + u |= 1 << KPF_MMAP; + if (PageAnon(page)) + u |= 1 << KPF_ANON; + } + + /* + * compound pages: export both head/tail info + * they together define a compound page's start/end pos and order + */ + if (PageHead(page)) + u |= 1 << KPF_COMPOUND_HEAD; + if (PageTail(page)) + u |= 1 << KPF_COMPOUND_TAIL; + + kpf_copy_bit(u, k, 1, KPF_LOCKED, PG_locked); + + kpf_copy_bit(u, k, 1, KPF_SLAB, PG_slab); + kpf_copy_bit(u, k, 1, KPF_BUDDY, PG_buddy); + + kpf_copy_bit(u, k, io, KPF_ERROR, PG_error); + kpf_copy_bit(u, k, io, KPF_DIRTY, PG_dirty); + kpf_copy_bit(u, k, io, KPF_UPTODATE, PG_uptodate); + kpf_copy_bit(u, k, io, KPF_WRITEBACK, PG_writeback); + + kpf_copy_bit(u, k, 1, KPF_LRU, PG_lru); + kpf_copy_bit(u, k, lru, KPF_REFERENCED, PG_referenced); + kpf_copy_bit(u, k, lru, KPF_ACTIVE, PG_active); + kpf_copy_bit(u, k, lru, KPF_RECLAIM, PG_reclaim); + + kpf_copy_bit(u, k, lru, KPF_SWAPCACHE, PG_swapcache); + kpf_copy_bit(u, k, lru, KPF_SWAPBACKED, PG_swapbacked); + +#ifdef CONFIG_MEMORY_FAILURE + kpf_copy_bit(u, k, 1, KPF_POISON, PG_poison); +#endif + +#ifdef CONFIG_UNEVICTABLE_LRU + kpf_copy_bit(u, k, lru, KPF_UNEVICTABLE, PG_unevictable); + kpf_copy_bit(u, k, 0, KPF_MLOCKED, PG_mlocked); +#endif + + kpf_copy_bit(u, k, 0, KPF_RESERVED, PG_reserved); + kpf_copy_bit(u, k, 0, KPF_MAPPEDTODISK, PG_mappedtodisk); + kpf_copy_bit(u, k, 0, KPF_PRIVATE, PG_private); + kpf_copy_bit(u, k, 0, KPF_PRIVATE2, PG_private_2); + kpf_copy_bit(u, k, 0, KPF_OWNER_PRIVATE, PG_owner_priv_1); + kpf_copy_bit(u, k, 0, KPF_ARCH, PG_arch_1); + +#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR + kpf_copy_bit(u, k, 0, KPF_UNCACHED, PG_uncached); +#endif + + if (!genuine_linus()) { + /* + * SLAB/SLOB/SLUB overload some page flags which may confuse end user + */ + if (slab) { + u &= ~ ((1 << KPF_ACTIVE) | + (1 << KPF_ERROR) | + (1 << KPF_MMAP)); + } + /* + * PG_reclaim could be overloaded as PG_readahead, + * and we only want to export the first one. + */ + if ((u & ((1 << KPF_RECLAIM) | (1 << KPF_WRITEBACK))) == + (1 << KPF_RECLAIM)) + u &= ~ (1 << KPF_RECLAIM); + } + + return u; +}; static ssize_t kpageflags_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) @@ -90,7 +239,6 @@ static ssize_t kpageflags_read(struct fi unsigned long src = *ppos; unsigned long pfn; ssize_t ret = 0; - u64 kflags, uflags; pfn = src / KPMSIZE; count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); @@ -98,32 +246,17 @@ static ssize_t kpageflags_read(struct fi return -EINVAL; while (count > 0) { - ppage = NULL; if (pfn_valid(pfn)) ppage = pfn_to_page(pfn); - pfn++; - if (!ppage) - kflags = 0; else - kflags = ppage->flags; - - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); + ppage = NULL; - if (put_user(uflags, out++)) { + if (put_user(get_uflags(ppage), out)) { ret = -EFAULT; break; } - + out++; + pfn++; count -= KPMSIZE; } --- mm.orig/Documentation/vm/pagemap.txt +++ mm/Documentation/vm/pagemap.txt @@ -12,9 +12,9 @@ There are three components to pagemap: value for each virtual page, containing the following data (from fs/proc/task_mmu.c, above pagemap_read): - * Bits 0-55 page frame number (PFN) if present + * Bits 0-54 page frame number (PFN) if present * Bits 0-4 swap type if swapped - * Bits 5-55 swap offset if swapped + * Bits 5-54 swap offset if swapped * Bits 55-60 page shift (page size = 1<<page shift) * Bit 61 reserved for future use * Bit 62 page swapped @@ -36,7 +36,7 @@ There are three components to pagemap: * /proc/kpageflags. This file contains a 64-bit set of flags for each page, indexed by PFN. - The flags are (from fs/proc/proc_misc, above kpageflags_read): + The flags are (from fs/proc/page.c, above kpageflags_read): 0. LOCKED 1. ERROR @@ -49,6 +49,65 @@ There are three components to pagemap: 8. WRITEBACK 9. RECLAIM 10. BUDDY + 11. MMAP + 12. ANON + 13. SWAPCACHE + 14. SWAPBACKED + 15. COMPOUND_HEAD + 16. COMPOUND_TAIL + 17. UNEVICTABLE + 18. POISON + 19. NOPAGE + +Short descriptions to the page flags: + + 0. LOCKED + page is being locked for exclusive access, eg. by undergoing read/write IO + + 7. SLAB + page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator + +10. BUDDY + a free memory block managed by the buddy system allocator + The buddy system organizes free memory in blocks of various orders. + An order N block has 2^N physically contiguous pages, with the BUDDY flag + set for and _only_ for the first page. + +15. COMPOUND_HEAD +16. COMPOUND_TAIL + A compound page with order N consists of 2^N physically contiguous pages. + A compound page with order 2 takes the form of "HTTT", where H donates its + head page and T donates its tail page(s). The major consumers of compound + pages are hugeTLB pages (Documentation/vm/hugetlbpage.txt), the SLUB etc. + memory allocators and various device drivers. + +18. POISON + hardware has detected memory corruption on this page + +19. NOPAGE + no page frame exists at the requested address + + [IO related page flags] + 1. ERROR IO error occurred + 3. UPTODATE page has up-to-date data + ie. for file backed page: (in-memory data revision >= on-disk one) + 4. DIRTY page has been written to, hence contains new data + ie. for file backed page: (in-memory data revision > on-disk one) + 8. WRITEBACK page is being synced to disk + + [LRU related page flags] + 5. LRU page is in one of the LRU lists + 6. ACTIVE page is in the active LRU list +17. UNEVICTABLE page is in the unevictable (non-)LRU list + It is somehow pinned and not a candidate for LRU page reclaims, + eg. ramfs pages, shmctl(SHM_LOCK) and mlock() memory segments + 2. REFERENCED page has been referenced since last LRU list enqueue/requeue + 9. RECLAIM page will be reclaimed soon after its pageout IO completed +11. MMAP a memory mapped page +12. ANON a memory mapped page who is not a file page +13. SWAPCACHE page is mapped to swap space, ie. has an associated swap entry +14. SWAPBACKED page is backed by swap/RAM + Using pagemap to do something useful: -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) 2009-04-23 2:26 ` Wu Fengguang @ 2009-04-23 7:48 ` Andi Kleen -1 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-23 7:48 UTC (permalink / raw) To: Wu Fengguang; +Cc: KOSAKI Motohiro, Andi Kleen, Andrew Morton, LKML, linux-mm On Thu, Apr 23, 2009 at 10:26:25AM +0800, Wu Fengguang wrote: > Andi and KOSAKI: can we hopefully reach harmony of opinions on this version? Haven't read the patch sorry, just comments on the text. > > Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers. > > 1) for kernel hackers (on CONFIG_DEBUG_KERNEL) > - all available page flags are exported, and > - exported as is So the interface changes based on that option? That would be unfortunate if true. > 2) for admins and end users > - only the more `well known' flags are exported: > 11. KPF_MMAP (pseudo flag) memory mapped page > 12. KPF_ANON (pseudo flag) memory mapped page (anonymous) > 13. KPF_SWAPCACHE page is in swap cache > 14. KPF_SWAPBACKED page is swap/RAM backed > 15. KPF_COMPOUND_HEAD (*) > 16. KPF_COMPOUND_TAIL (*) > 17. KPF_UNEVICTABLE page is in the unevictable LRU list > 18. KPF_POISON hardware detected corruption > 19. KPF_NOPAGE (pseudo flag) no page frame at the address I think DIRTY should be in that list. > > (*) For compound pages, exporting _both_ head/tail info enables > users to tell where a compound page starts/ends, and its order. > > - limit flags to their typical usage scenario, as indicated by KOSAKI: > - LRU pages: only export relevant flags > - PG_lru > - PG_unevictable > - PG_active And active too because it's already exported in /proc/meminfo > - PG_dirty > - PG_uptodate > - PG_writeback > - SLAB pages: mask out overloaded flags: > - PG_error Error should be exported too, it has straight forward semantics and could be useful to the admin. > - admins may wonder where all the compound pages gone - the use of > compound pages in SLUB might have some real world relevance, so that > end users want to be aware of this behavior I'm not sure why it uses compound pages at all. It would be nicer if compound pages were limited to huge pages, and then start/tail wouldn't be needed. -Andi -- ak@linux.intel.com -- Speaking for myself only. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) @ 2009-04-23 7:48 ` Andi Kleen 0 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-23 7:48 UTC (permalink / raw) To: Wu Fengguang; +Cc: KOSAKI Motohiro, Andi Kleen, Andrew Morton, LKML, linux-mm On Thu, Apr 23, 2009 at 10:26:25AM +0800, Wu Fengguang wrote: > Andi and KOSAKI: can we hopefully reach harmony of opinions on this version? Haven't read the patch sorry, just comments on the text. > > Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers. > > 1) for kernel hackers (on CONFIG_DEBUG_KERNEL) > - all available page flags are exported, and > - exported as is So the interface changes based on that option? That would be unfortunate if true. > 2) for admins and end users > - only the more `well known' flags are exported: > 11. KPF_MMAP (pseudo flag) memory mapped page > 12. KPF_ANON (pseudo flag) memory mapped page (anonymous) > 13. KPF_SWAPCACHE page is in swap cache > 14. KPF_SWAPBACKED page is swap/RAM backed > 15. KPF_COMPOUND_HEAD (*) > 16. KPF_COMPOUND_TAIL (*) > 17. KPF_UNEVICTABLE page is in the unevictable LRU list > 18. KPF_POISON hardware detected corruption > 19. KPF_NOPAGE (pseudo flag) no page frame at the address I think DIRTY should be in that list. > > (*) For compound pages, exporting _both_ head/tail info enables > users to tell where a compound page starts/ends, and its order. > > - limit flags to their typical usage scenario, as indicated by KOSAKI: > - LRU pages: only export relevant flags > - PG_lru > - PG_unevictable > - PG_active And active too because it's already exported in /proc/meminfo > - PG_dirty > - PG_uptodate > - PG_writeback > - SLAB pages: mask out overloaded flags: > - PG_error Error should be exported too, it has straight forward semantics and could be useful to the admin. > - admins may wonder where all the compound pages gone - the use of > compound pages in SLUB might have some real world relevance, so that > end users want to be aware of this behavior I'm not sure why it uses compound pages at all. It would be nicer if compound pages were limited to huge pages, and then start/tail wouldn't be needed. -Andi -- ak@linux.intel.com -- Speaking for myself only. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) 2009-04-23 7:48 ` Andi Kleen @ 2009-04-23 8:10 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-23 8:10 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Thu, Apr 23, 2009 at 03:48:48PM +0800, Andi Kleen wrote: > On Thu, Apr 23, 2009 at 10:26:25AM +0800, Wu Fengguang wrote: > > Andi and KOSAKI: can we hopefully reach harmony of opinions on this version? > > Haven't read the patch sorry, just comments on the text. > > > > > Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers. > > > > 1) for kernel hackers (on CONFIG_DEBUG_KERNEL) > > - all available page flags are exported, and > > - exported as is > > So the interface changes based on that option? That would > be unfortunate if true. To be exact, it's "extend the view" on CONFIG_DEBUG_KERNEL. The meanings won't change, you simply see more flags that didn't turn up when !CONFIG_DEBUG_KERNEL. > > 2) for admins and end users > > - only the more `well known' flags are exported: > > 11. KPF_MMAP (pseudo flag) memory mapped page > > 12. KPF_ANON (pseudo flag) memory mapped page (anonymous) > > 13. KPF_SWAPCACHE page is in swap cache > > 14. KPF_SWAPBACKED page is swap/RAM backed > > 15. KPF_COMPOUND_HEAD (*) > > 16. KPF_COMPOUND_TAIL (*) > > 17. KPF_UNEVICTABLE page is in the unevictable LRU list > > 18. KPF_POISON hardware detected corruption > > 19. KPF_NOPAGE (pseudo flag) no page frame at the address > > I think DIRTY should be in that list. It has been there. ERROR, DIRTY and ACTIVE were exported at the time this interface was initially introduced: #define KPF_LOCKED 0 ==> #define KPF_ERROR 1 #define KPF_REFERENCED 2 #define KPF_UPTODATE 3 ==> #define KPF_DIRTY 4 #define KPF_LRU 5 ==> #define KPF_ACTIVE 6 #define KPF_SLAB 7 #define KPF_WRITEBACK 8 #define KPF_RECLAIM 9 #define KPF_BUDDY 10 > > > > (*) For compound pages, exporting _both_ head/tail info enables > > users to tell where a compound page starts/ends, and its order. > > > > - limit flags to their typical usage scenario, as indicated by KOSAKI: > > - LRU pages: only export relevant flags > > - PG_lru > > - PG_unevictable > > - PG_active > > And active too because it's already exported in /proc/meminfo ditto > > - PG_dirty > > - PG_uptodate > > - PG_writeback > > - SLAB pages: mask out overloaded flags: > > - PG_error > > Error should be exported too, it has straight forward semantics > and could be useful to the admin. ditto > > - admins may wonder where all the compound pages gone - the use of > > compound pages in SLUB might have some real world relevance, so that > > end users want to be aware of this behavior > > I'm not sure why it uses compound pages at all. It would be nicer > if compound pages were limited to huge pages, and then start/tail > wouldn't be needed. Good idea. Would you recommend a good way to identify huge pages? Test by page order, or by (dtor == free_huge_page)? Thanks, Fengguang ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) @ 2009-04-23 8:10 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-23 8:10 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Thu, Apr 23, 2009 at 03:48:48PM +0800, Andi Kleen wrote: > On Thu, Apr 23, 2009 at 10:26:25AM +0800, Wu Fengguang wrote: > > Andi and KOSAKI: can we hopefully reach harmony of opinions on this version? > > Haven't read the patch sorry, just comments on the text. > > > > > Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers. > > > > 1) for kernel hackers (on CONFIG_DEBUG_KERNEL) > > - all available page flags are exported, and > > - exported as is > > So the interface changes based on that option? That would > be unfortunate if true. To be exact, it's "extend the view" on CONFIG_DEBUG_KERNEL. The meanings won't change, you simply see more flags that didn't turn up when !CONFIG_DEBUG_KERNEL. > > 2) for admins and end users > > - only the more `well known' flags are exported: > > 11. KPF_MMAP (pseudo flag) memory mapped page > > 12. KPF_ANON (pseudo flag) memory mapped page (anonymous) > > 13. KPF_SWAPCACHE page is in swap cache > > 14. KPF_SWAPBACKED page is swap/RAM backed > > 15. KPF_COMPOUND_HEAD (*) > > 16. KPF_COMPOUND_TAIL (*) > > 17. KPF_UNEVICTABLE page is in the unevictable LRU list > > 18. KPF_POISON hardware detected corruption > > 19. KPF_NOPAGE (pseudo flag) no page frame at the address > > I think DIRTY should be in that list. It has been there. ERROR, DIRTY and ACTIVE were exported at the time this interface was initially introduced: #define KPF_LOCKED 0 ==> #define KPF_ERROR 1 #define KPF_REFERENCED 2 #define KPF_UPTODATE 3 ==> #define KPF_DIRTY 4 #define KPF_LRU 5 ==> #define KPF_ACTIVE 6 #define KPF_SLAB 7 #define KPF_WRITEBACK 8 #define KPF_RECLAIM 9 #define KPF_BUDDY 10 > > > > (*) For compound pages, exporting _both_ head/tail info enables > > users to tell where a compound page starts/ends, and its order. > > > > - limit flags to their typical usage scenario, as indicated by KOSAKI: > > - LRU pages: only export relevant flags > > - PG_lru > > - PG_unevictable > > - PG_active > > And active too because it's already exported in /proc/meminfo ditto > > - PG_dirty > > - PG_uptodate > > - PG_writeback > > - SLAB pages: mask out overloaded flags: > > - PG_error > > Error should be exported too, it has straight forward semantics > and could be useful to the admin. ditto > > - admins may wonder where all the compound pages gone - the use of > > compound pages in SLUB might have some real world relevance, so that > > end users want to be aware of this behavior > > I'm not sure why it uses compound pages at all. It would be nicer > if compound pages were limited to huge pages, and then start/tail > wouldn't be needed. Good idea. Would you recommend a good way to identify huge pages? Test by page order, or by (dtor == free_huge_page)? Thanks, Fengguang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) 2009-04-23 8:10 ` Wu Fengguang @ 2009-04-23 8:54 ` Andi Kleen -1 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-23 8:54 UTC (permalink / raw) To: Wu Fengguang; +Cc: Andi Kleen, KOSAKI Motohiro, Andrew Morton, LKML, linux-mm > Good idea. > > Would you recommend a good way to identify huge pages? > Test by page order, or by (dtor == free_huge_page)? That doesn't work for GB pages. The best way would be to make slub stop using it and then check for compound, but I don't know what this implies. Otherwise would need some other way, perhaps a new flag? -Andi -- ak@linux.intel.com -- Speaking for myself only. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) @ 2009-04-23 8:54 ` Andi Kleen 0 siblings, 0 replies; 44+ messages in thread From: Andi Kleen @ 2009-04-23 8:54 UTC (permalink / raw) To: Wu Fengguang; +Cc: Andi Kleen, KOSAKI Motohiro, Andrew Morton, LKML, linux-mm > Good idea. > > Would you recommend a good way to identify huge pages? > Test by page order, or by (dtor == free_huge_page)? That doesn't work for GB pages. The best way would be to make slub stop using it and then check for compound, but I don't know what this implies. Otherwise would need some other way, perhaps a new flag? -Andi -- ak@linux.intel.com -- Speaking for myself only. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) 2009-04-23 8:54 ` Andi Kleen @ 2009-04-23 11:21 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-23 11:21 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Thu, Apr 23, 2009 at 04:54:06PM +0800, Andi Kleen wrote: > > Good idea. > > > > Would you recommend a good way to identify huge pages? > > Test by page order, or by (dtor == free_huge_page)? > > That doesn't work for GB pages. The best way would be to make > slub stop using it and then check for compound, but I don't know what > this implies. Otherwise would need some other way, perhaps a new > flag? Or play the following trick? :-) This helps hide the internal compound page consumers(SLAB/SLUB/... and loads of device drivers) to user space. However there are still huge pages of different orders(IA64?). Does this make a good reason for exporting both HEAD/TAIL flags, instead of a combined COMPOUND flag? Thanks, Fengguang --- diff --git a/mm/page_alloc.c b/mm/page_alloc.c index c722aa6..7d0bd0d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -298,6 +298,14 @@ void prep_compound_page(struct page *page, unsigned long order) } } +/* + * This function helps distinguish gigantic pages from normal compound pages. + */ +static void free_gigantic_page(struct page *page) +{ + __free_pages_ok(page, compound_order(page)); +} + #ifdef CONFIG_HUGETLBFS void prep_compound_gigantic_page(struct page *page, unsigned long order) { @@ -305,7 +313,7 @@ void prep_compound_gigantic_page(struct page *page, unsigned long order) int nr_pages = 1 << order; struct page *p = page + 1; - set_compound_page_dtor(page, free_compound_page); + set_compound_page_dtor(page, free_gigantic_page); set_compound_order(page, order); __SetPageHead(page); for (i = 1; i < nr_pages; i++, p = mem_map_next(p, page, i)) { ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) @ 2009-04-23 11:21 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-23 11:21 UTC (permalink / raw) To: Andi Kleen; +Cc: KOSAKI Motohiro, Andrew Morton, LKML, linux-mm On Thu, Apr 23, 2009 at 04:54:06PM +0800, Andi Kleen wrote: > > Good idea. > > > > Would you recommend a good way to identify huge pages? > > Test by page order, or by (dtor == free_huge_page)? > > That doesn't work for GB pages. The best way would be to make > slub stop using it and then check for compound, but I don't know what > this implies. Otherwise would need some other way, perhaps a new > flag? Or play the following trick? :-) This helps hide the internal compound page consumers(SLAB/SLUB/... and loads of device drivers) to user space. However there are still huge pages of different orders(IA64?). Does this make a good reason for exporting both HEAD/TAIL flags, instead of a combined COMPOUND flag? Thanks, Fengguang --- diff --git a/mm/page_alloc.c b/mm/page_alloc.c index c722aa6..7d0bd0d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -298,6 +298,14 @@ void prep_compound_page(struct page *page, unsigned long order) } } +/* + * This function helps distinguish gigantic pages from normal compound pages. + */ +static void free_gigantic_page(struct page *page) +{ + __free_pages_ok(page, compound_order(page)); +} + #ifdef CONFIG_HUGETLBFS void prep_compound_gigantic_page(struct page *page, unsigned long order) { @@ -305,7 +313,7 @@ void prep_compound_gigantic_page(struct page *page, unsigned long order) int nr_pages = 1 << order; struct page *p = page + 1; - set_compound_page_dtor(page, free_compound_page); + set_compound_page_dtor(page, free_gigantic_page); set_compound_order(page, order); __SetPageHead(page); for (i = 1; i < nr_pages; i++, p = mem_map_next(p, page, i)) { -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) 2009-04-23 2:26 ` Wu Fengguang (?) (?) @ 2009-04-25 1:59 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-25 1:59 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andi Kleen, Andrew Morton, LKML, linux-mm [-- Attachment #1: Type: text/plain, Size: 19254 bytes --] Hi all, For your convenience, I attached the uptodate code for page-types and page-areas. Enjoy hacking~ Thanks, Fengguang On Thu, Apr 23, 2009 at 10:26:25AM +0800, Wu Fengguang wrote: > Andi and KOSAKI: can we hopefully reach harmony of opinions on this version? > > Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers. > > 1) for kernel hackers (on CONFIG_DEBUG_KERNEL) > - all available page flags are exported, and > - exported as is > 2) for admins and end users > - only the more `well known' flags are exported: > 11. KPF_MMAP (pseudo flag) memory mapped page > 12. KPF_ANON (pseudo flag) memory mapped page (anonymous) > 13. KPF_SWAPCACHE page is in swap cache > 14. KPF_SWAPBACKED page is swap/RAM backed > 15. KPF_COMPOUND_HEAD (*) > 16. KPF_COMPOUND_TAIL (*) > 17. KPF_UNEVICTABLE page is in the unevictable LRU list > 18. KPF_POISON hardware detected corruption > 19. KPF_NOPAGE (pseudo flag) no page frame at the address > > (*) For compound pages, exporting _both_ head/tail info enables > users to tell where a compound page starts/ends, and its order. > > - limit flags to their typical usage scenario, as indicated by KOSAKI: > - LRU pages: only export relevant flags > - PG_lru > - PG_unevictable > - PG_active > - PG_referenced > - page_mapped() > - PageAnon() > - PG_swapcache > - PG_swapbacked > - PG_reclaim > - no-IO pages: mask out irrelevant flags > - PG_dirty > - PG_uptodate > - PG_writeback > - SLAB pages: mask out overloaded flags: > - PG_error > - PG_active > - PG_private > - PG_reclaim: filter out the overloaded PG_readahead > > Note that compound page flags are exported faithfully to end user. This risks > exposing internal implementation details of the SLUB allocator, however hiding > it risks larger impacts: > - admins may wonder where all the compound pages gone - the use of > compound pages in SLUB might have some real world relevance, so that > end users want to be aware of this behavior > - admins may be confused on inconsistent number of head/tail segments > This is because SLUB only marks PG_slab on the compound head page. > If we mask out PG_head|PG_tail for PG_slab pages, we are actually > only masking out PG_head flags. Therefore the PG_tail segments will > outnumber PG_head ones, which puzzled me for some time.. > > Here are the admin/linus views of all page flags on a newly booted nfs-root system: > > # ./page-types # for admin > flags page-count MB symbolic-flags long-symbolic-flags > 0x000000000000 491449 1919 ____________________________ > 0x000000008000 15 0 _______________H____________ compound_head > 0x000000010000 4280 16 ________________T___________ compound_tail > 0x000000000008 17 0 ___U________________________ uptodate > 0x000000008010 1 0 ____D__________H____________ dirty,compound_head > 0x000000010010 4 0 ____D___________T___________ dirty,compound_tail > 0x000000000020 1 0 _____l______________________ lru > 0x000000000028 2678 10 ___U_l______________________ uptodate,lru > 0x00000000002c 5244 20 __RU_l______________________ referenced,uptodate,lru > 0x000000004060 1 0 _____lA_______b_____________ lru,active,swapbacked > 0x000000004064 13 0 __R__lA_______b_____________ referenced,lru,active,swapbacked > 0x000000000068 236 0 ___U_lA_____________________ uptodate,lru,active > 0x00000000006c 927 3 __RU_lA_____________________ referenced,uptodate,lru,active > 0x000000008080 968 3 _______S_______H____________ slab,compound_head > 0x000000000080 1539 6 _______S____________________ slab > 0x000000000400 516 2 __________B_________________ buddy > 0x000000000828 1142 4 ___U_l_____M________________ uptodate,lru,mmap > 0x00000000082c 280 1 __RU_l_____M________________ referenced,uptodate,lru,mmap > 0x000000004860 2 0 _____lA____M__b_____________ lru,active,mmap,swapbacked > 0x000000000868 366 1 ___U_lA____M________________ uptodate,lru,active,mmap > 0x00000000086c 623 2 __RU_lA____M________________ referenced,uptodate,lru,active,mmap > 0x000000005868 3639 14 ___U_lA____Ma_b_____________ uptodate,lru,active,mmap,anonymous,swapbacked > 0x00000000586c 27 0 __RU_lA____Ma_b_____________ referenced,uptodate,lru,active,mmap,anonymous,swapbacked > total 513968 2007 > > # ./page-types # for linus, when CONFIG_DEBUG_KERNEL is turned on > flags page-count MB symbolic-flags long-symbolic-flags > 0x000000000000 471731 1842 ____________________________ > 0x000100000000 19258 75 ____________________r_______ reserved > 0x000000008000 15 0 _______________H____________ compound_head > 0x000000010000 4270 16 ________________T___________ compound_tail > 0x000000000008 3 0 ___U________________________ uptodate > 0x000000008014 1 0 __R_D__________H____________ referenced,dirty,compound_head > 0x000000010014 4 0 __R_D___________T___________ referenced,dirty,compound_tail > 0x000000000020 1 0 _____l______________________ lru > 0x000000000028 2626 10 ___U_l______________________ uptodate,lru > 0x00000000002c 5244 20 __RU_l______________________ referenced,uptodate,lru > 0x000000000068 238 0 ___U_lA_____________________ uptodate,lru,active > 0x00000000006c 925 3 __RU_lA_____________________ referenced,uptodate,lru,active > 0x000000004078 1 0 ___UDlA_______b_____________ uptodate,dirty,lru,active,swapbacked > 0x00000000407c 13 0 __RUDlA_______b_____________ referenced,uptodate,dirty,lru,active,swapbacked > 0x000000000228 49 0 ___U_l___I__________________ uptodate,lru,reclaim > 0x000000000400 523 2 __________B_________________ buddy > 0x000000000804 1 0 __R________M________________ referenced,mmap > 0x00000000080c 1 0 __RU_______M________________ referenced,uptodate,mmap > 0x000000000828 1142 4 ___U_l_____M________________ uptodate,lru,mmap > 0x00000000082c 280 1 __RU_l_____M________________ referenced,uptodate,lru,mmap > 0x000000000868 366 1 ___U_lA____M________________ uptodate,lru,active,mmap > 0x00000000086c 622 2 __RU_lA____M________________ referenced,uptodate,lru,active,mmap > 0x000000004878 2 0 ___UDlA____M__b_____________ uptodate,dirty,lru,active,mmap,swapbacked > 0x000000008880 907 3 _______S___M___H____________ slab,mmap,compound_head > 0x000000000880 1488 5 _______S___M________________ slab,mmap > 0x0000000088c0 59 0 ______AS___M___H____________ active,slab,mmap,compound_head > 0x0000000008c0 49 0 ______AS___M________________ active,slab,mmap > 0x000000001000 465 1 ____________a_______________ anonymous > 0x000000005008 8 0 ___U________a_b_____________ uptodate,anonymous,swapbacked > 0x000000005808 4 0 ___U_______Ma_b_____________ uptodate,mmap,anonymous,swapbacked > 0x00000000580c 1 0 __RU_______Ma_b_____________ referenced,uptodate,mmap,anonymous,swapbacked > 0x000000005868 3645 14 ___U_lA____Ma_b_____________ uptodate,lru,active,mmap,anonymous,swapbacked > 0x00000000586c 26 0 __RU_lA____Ma_b_____________ referenced,uptodate,lru,active,mmap,anonymous,swapbacked > total 513968 2007 > > Kudos to KOSAKI and Andi for the extensive recommendations! > > Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> > Cc: Andi Kleen <andi@firstfloor.org> > Cc: Matt Mackall <mpm@selenic.com> > Cc: Alexey Dobriyan <adobriyan@gmail.com> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > --- > Documentation/vm/pagemap.txt | 65 ++++++++++ > fs/proc/page.c | 197 +++++++++++++++++++++++++++------ > 2 files changed, 227 insertions(+), 35 deletions(-) > > --- mm.orig/fs/proc/page.c > +++ mm/fs/proc/page.c > @@ -6,6 +6,7 @@ > #include <linux/mmzone.h> > #include <linux/proc_fs.h> > #include <linux/seq_file.h> > +#include <linux/backing-dev.h> > #include <asm/uaccess.h> > #include "internal.h" > > @@ -68,19 +69,167 @@ static const struct file_operations proc > > /* These macros are used to decouple internal flags from exported ones */ > > -#define KPF_LOCKED 0 > -#define KPF_ERROR 1 > -#define KPF_REFERENCED 2 > -#define KPF_UPTODATE 3 > -#define KPF_DIRTY 4 > -#define KPF_LRU 5 > -#define KPF_ACTIVE 6 > -#define KPF_SLAB 7 > -#define KPF_WRITEBACK 8 > -#define KPF_RECLAIM 9 > -#define KPF_BUDDY 10 > +#define KPF_LOCKED 0 > +#define KPF_ERROR 1 > +#define KPF_REFERENCED 2 > +#define KPF_UPTODATE 3 > +#define KPF_DIRTY 4 > +#define KPF_LRU 5 > +#define KPF_ACTIVE 6 > +#define KPF_SLAB 7 > +#define KPF_WRITEBACK 8 > +#define KPF_RECLAIM 9 > +#define KPF_BUDDY 10 > + > +/* new additions in 2.6.31 */ > +#define KPF_MMAP 11 > +#define KPF_ANON 12 > +#define KPF_SWAPCACHE 13 > +#define KPF_SWAPBACKED 14 > +#define KPF_COMPOUND_HEAD 15 > +#define KPF_COMPOUND_TAIL 16 > +#define KPF_UNEVICTABLE 17 > +#define KPF_POISON 18 > +#define KPF_NOPAGE 19 > + > +/* kernel hacking assistances */ > +#define KPF_RESERVED 32 > +#define KPF_MLOCKED 33 > +#define KPF_MAPPEDTODISK 34 > +#define KPF_PRIVATE 35 > +#define KPF_PRIVATE2 36 > +#define KPF_OWNER_PRIVATE 37 > +#define KPF_ARCH 38 > +#define KPF_UNCACHED 39 > + > +/* > + * Kernel flags are exported faithfully to Linus and his fellow hackers. > + * Otherwise some details are masked to avoid confusing the end user: > + * - some kernel flags are completely invisible > + * - some kernel flags are conditionally invisible on their odd usages > + */ > +#ifdef CONFIG_DEBUG_KERNEL > +static inline int genuine_linus(void) { return 1; } > +#else > +static inline int genuine_linus(void) { return 0; } > +#endif > + > +#define kpf_copy_bit(uflags, kflags, visible, ubit, kbit) \ > + do { \ > + if (visible || genuine_linus()) \ > + uflags |= ((kflags >> kbit) & 1) << ubit; \ > + } while (0); > + > +/* a helper function _not_ intended for more general uses */ > +static inline int page_cap_writeback_dirty(struct page *page) > +{ > + struct address_space *mapping = NULL; > + > + if (!PageSlab(page)) > + mapping = page_mapping(page); > + > + return !mapping || mapping_cap_writeback_dirty(mapping); > +} > > -#define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos) > +static u64 get_uflags(struct page *page) > +{ > + u64 k; > + u64 u; > + int io; > + int lru; > + int slab; > + > + /* > + * pseudo flag: KPF_NOPAGE > + * it differentiates a memory hole from a page with no flags > + */ > + if (!page) > + return 1 << KPF_NOPAGE; > + > + k = page->flags; > + u = 0; > + > + io = page_cap_writeback_dirty(page); > + lru = k & (1 << PG_lru); > + slab = k & (1 << PG_slab); > + > + /* > + * pseudo flags for the well known (anonymous) memory mapped pages > + */ > + if (lru || genuine_linus()) { > + if (page_mapped(page)) > + u |= 1 << KPF_MMAP; > + if (PageAnon(page)) > + u |= 1 << KPF_ANON; > + } > + > + /* > + * compound pages: export both head/tail info > + * they together define a compound page's start/end pos and order > + */ > + if (PageHead(page)) > + u |= 1 << KPF_COMPOUND_HEAD; > + if (PageTail(page)) > + u |= 1 << KPF_COMPOUND_TAIL; > + > + kpf_copy_bit(u, k, 1, KPF_LOCKED, PG_locked); > + > + kpf_copy_bit(u, k, 1, KPF_SLAB, PG_slab); > + kpf_copy_bit(u, k, 1, KPF_BUDDY, PG_buddy); > + > + kpf_copy_bit(u, k, io, KPF_ERROR, PG_error); > + kpf_copy_bit(u, k, io, KPF_DIRTY, PG_dirty); > + kpf_copy_bit(u, k, io, KPF_UPTODATE, PG_uptodate); > + kpf_copy_bit(u, k, io, KPF_WRITEBACK, PG_writeback); > + > + kpf_copy_bit(u, k, 1, KPF_LRU, PG_lru); > + kpf_copy_bit(u, k, lru, KPF_REFERENCED, PG_referenced); > + kpf_copy_bit(u, k, lru, KPF_ACTIVE, PG_active); > + kpf_copy_bit(u, k, lru, KPF_RECLAIM, PG_reclaim); > + > + kpf_copy_bit(u, k, lru, KPF_SWAPCACHE, PG_swapcache); > + kpf_copy_bit(u, k, lru, KPF_SWAPBACKED, PG_swapbacked); > + > +#ifdef CONFIG_MEMORY_FAILURE > + kpf_copy_bit(u, k, 1, KPF_POISON, PG_poison); > +#endif > + > +#ifdef CONFIG_UNEVICTABLE_LRU > + kpf_copy_bit(u, k, lru, KPF_UNEVICTABLE, PG_unevictable); > + kpf_copy_bit(u, k, 0, KPF_MLOCKED, PG_mlocked); > +#endif > + > + kpf_copy_bit(u, k, 0, KPF_RESERVED, PG_reserved); > + kpf_copy_bit(u, k, 0, KPF_MAPPEDTODISK, PG_mappedtodisk); > + kpf_copy_bit(u, k, 0, KPF_PRIVATE, PG_private); > + kpf_copy_bit(u, k, 0, KPF_PRIVATE2, PG_private_2); > + kpf_copy_bit(u, k, 0, KPF_OWNER_PRIVATE, PG_owner_priv_1); > + kpf_copy_bit(u, k, 0, KPF_ARCH, PG_arch_1); > + > +#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR > + kpf_copy_bit(u, k, 0, KPF_UNCACHED, PG_uncached); > +#endif > + > + if (!genuine_linus()) { > + /* > + * SLAB/SLOB/SLUB overload some page flags which may confuse end user > + */ > + if (slab) { > + u &= ~ ((1 << KPF_ACTIVE) | > + (1 << KPF_ERROR) | > + (1 << KPF_MMAP)); > + } > + /* > + * PG_reclaim could be overloaded as PG_readahead, > + * and we only want to export the first one. > + */ > + if ((u & ((1 << KPF_RECLAIM) | (1 << KPF_WRITEBACK))) == > + (1 << KPF_RECLAIM)) > + u &= ~ (1 << KPF_RECLAIM); > + } > + > + return u; > +}; > > static ssize_t kpageflags_read(struct file *file, char __user *buf, > size_t count, loff_t *ppos) > @@ -90,7 +239,6 @@ static ssize_t kpageflags_read(struct fi > unsigned long src = *ppos; > unsigned long pfn; > ssize_t ret = 0; > - u64 kflags, uflags; > > pfn = src / KPMSIZE; > count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src); > @@ -98,32 +246,17 @@ static ssize_t kpageflags_read(struct fi > return -EINVAL; > > while (count > 0) { > - ppage = NULL; > if (pfn_valid(pfn)) > ppage = pfn_to_page(pfn); > - pfn++; > - if (!ppage) > - kflags = 0; > else > - kflags = ppage->flags; > - > - uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) | > - kpf_copy_bit(kflags, KPF_ERROR, PG_error) | > - kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) | > - kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) | > - kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) | > - kpf_copy_bit(kflags, KPF_LRU, PG_lru) | > - kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) | > - kpf_copy_bit(kflags, KPF_SLAB, PG_slab) | > - kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) | > - kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) | > - kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy); > + ppage = NULL; > > - if (put_user(uflags, out++)) { > + if (put_user(get_uflags(ppage), out)) { > ret = -EFAULT; > break; > } > - > + out++; > + pfn++; > count -= KPMSIZE; > } > > --- mm.orig/Documentation/vm/pagemap.txt > +++ mm/Documentation/vm/pagemap.txt > @@ -12,9 +12,9 @@ There are three components to pagemap: > value for each virtual page, containing the following data (from > fs/proc/task_mmu.c, above pagemap_read): > > - * Bits 0-55 page frame number (PFN) if present > + * Bits 0-54 page frame number (PFN) if present > * Bits 0-4 swap type if swapped > - * Bits 5-55 swap offset if swapped > + * Bits 5-54 swap offset if swapped > * Bits 55-60 page shift (page size = 1<<page shift) > * Bit 61 reserved for future use > * Bit 62 page swapped > @@ -36,7 +36,7 @@ There are three components to pagemap: > * /proc/kpageflags. This file contains a 64-bit set of flags for each > page, indexed by PFN. > > - The flags are (from fs/proc/proc_misc, above kpageflags_read): > + The flags are (from fs/proc/page.c, above kpageflags_read): > > 0. LOCKED > 1. ERROR > @@ -49,6 +49,65 @@ There are three components to pagemap: > 8. WRITEBACK > 9. RECLAIM > 10. BUDDY > + 11. MMAP > + 12. ANON > + 13. SWAPCACHE > + 14. SWAPBACKED > + 15. COMPOUND_HEAD > + 16. COMPOUND_TAIL > + 17. UNEVICTABLE > + 18. POISON > + 19. NOPAGE > + > +Short descriptions to the page flags: > + > + 0. LOCKED > + page is being locked for exclusive access, eg. by undergoing read/write IO > + > + 7. SLAB > + page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator > + > +10. BUDDY > + a free memory block managed by the buddy system allocator > + The buddy system organizes free memory in blocks of various orders. > + An order N block has 2^N physically contiguous pages, with the BUDDY flag > + set for and _only_ for the first page. > + > +15. COMPOUND_HEAD > +16. COMPOUND_TAIL > + A compound page with order N consists of 2^N physically contiguous pages. > + A compound page with order 2 takes the form of "HTTT", where H donates its > + head page and T donates its tail page(s). The major consumers of compound > + pages are hugeTLB pages (Documentation/vm/hugetlbpage.txt), the SLUB etc. > + memory allocators and various device drivers. > + > +18. POISON > + hardware has detected memory corruption on this page > + > +19. NOPAGE > + no page frame exists at the requested address > + > + [IO related page flags] > + 1. ERROR IO error occurred > + 3. UPTODATE page has up-to-date data > + ie. for file backed page: (in-memory data revision >= on-disk one) > + 4. DIRTY page has been written to, hence contains new data > + ie. for file backed page: (in-memory data revision > on-disk one) > + 8. WRITEBACK page is being synced to disk > + > + [LRU related page flags] > + 5. LRU page is in one of the LRU lists > + 6. ACTIVE page is in the active LRU list > +17. UNEVICTABLE page is in the unevictable (non-)LRU list > + It is somehow pinned and not a candidate for LRU page reclaims, > + eg. ramfs pages, shmctl(SHM_LOCK) and mlock() memory segments > + 2. REFERENCED page has been referenced since last LRU list enqueue/requeue > + 9. RECLAIM page will be reclaimed soon after its pageout IO completed > +11. MMAP a memory mapped page > +12. ANON a memory mapped page who is not a file page > +13. SWAPCACHE page is mapped to swap space, ie. has an associated swap entry > +14. SWAPBACKED page is backed by swap/RAM > + > > Using pagemap to do something useful: > [-- Attachment #2: pagemap.h --] [-- Type: text/x-chdr, Size: 2400 bytes --] #ifndef _PAGEMAP_H_ #define _PAGEMAP_H_ #define KPF_BYTES 8 #define PROC_KPAGEFLAGS "/proc/kpageflags" #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) /* copied from kpageflags_read() */ #define KPF_LOCKED 0 #define KPF_ERROR 1 #define KPF_REFERENCED 2 #define KPF_UPTODATE 3 #define KPF_DIRTY 4 #define KPF_LRU 5 #define KPF_ACTIVE 6 #define KPF_SLAB 7 #define KPF_WRITEBACK 8 #define KPF_RECLAIM 9 #define KPF_BUDDY 10 /* new additions in 2.6.31 */ #define KPF_MMAP 11 #define KPF_ANON 12 #define KPF_SWAPCACHE 13 #define KPF_SWAPBACKED 14 #define KPF_COMPOUND_HEAD 15 #define KPF_COMPOUND_TAIL 16 #define KPF_UNEVICTABLE 17 #define KPF_POISON 18 #define KPF_NOPAGE 19 /* kernel hacking assistances */ #define KPF_RESERVED 32 #define KPF_MLOCKED 33 #define KPF_MAPPEDTODISK 34 #define KPF_PRIVATE 35 #define KPF_PRIVATE2 36 #define KPF_OWNER_PRIVATE 37 #define KPF_ARCH 38 #define KPF_UNCACHED 39 static char *page_flag_names[] = { [KPF_LOCKED] = "L:locked", [KPF_ERROR] = "E:error", [KPF_REFERENCED] = "R:referenced", [KPF_UPTODATE] = "U:uptodate", [KPF_DIRTY] = "D:dirty", [KPF_LRU] = "l:lru", [KPF_ACTIVE] = "A:active", [KPF_SLAB] = "S:slab", [KPF_WRITEBACK] = "W:writeback", [KPF_RECLAIM] = "I:reclaim", [KPF_BUDDY] = "B:buddy", [KPF_MMAP] = "M:mmap", [KPF_ANON] = "a:anonymous", [KPF_SWAPCACHE] = "s:swapcache", [KPF_SWAPBACKED] = "b:swapbacked", [KPF_COMPOUND_HEAD] = "H:compound_head", [KPF_COMPOUND_TAIL] = "T:compound_tail", [KPF_UNEVICTABLE] = "u:unevictable", [KPF_POISON] = "X:poison", [KPF_NOPAGE] = "n:nopage", [KPF_RESERVED] = "r:reserved", [KPF_MLOCKED] = "m:mlocked", [KPF_MAPPEDTODISK] = "d:mappedtodisk", [KPF_PRIVATE] = "P:private", [KPF_PRIVATE2] = "p:private_2", [KPF_OWNER_PRIVATE] = "O:owner_private", [KPF_ARCH] = "h:arch", [KPF_UNCACHED] = "c:uncached", }; static inline unsigned long pages2kb(unsigned long pages) { return (pages * getpagesize()) >> 10; } static inline unsigned long pages2mb(unsigned long pages) { return (pages * getpagesize()) >> 20; } #endif /* _PAGEMAP_H_ */ [-- Attachment #3: page-types.c --] [-- Type: text/x-csrc, Size: 2656 bytes --] #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdint.h> #include <sys/types.h> #include <sys/errno.h> #include <sys/fcntl.h> #include "pagemap.h" #define HASH_SHIFT 13 #define HASH_MASK ((1 << HASH_SHIFT) - 1) #define HASH_KEY(flags) (flags & HASH_MASK) static unsigned long page_count[1 << HASH_SHIFT]; static uint64_t page_flags[1 << HASH_SHIFT]; int hash_index(uint64_t flags) { int i; int k = HASH_KEY(flags); if (!flags) return 0; for (i = 1; i < ARRAY_SIZE(page_count); i++, k++) { if (!k || k >= ARRAY_SIZE(page_count)) k = 1; if (page_flags[k] == 0) { page_flags[k] = flags; return k; } if (page_flags[k] == flags) return k; } exit(1); /* die hard on full hash table */ } char *page_flag_name(uint64_t flags) { int i, j; int bit; static char buf[65]; for (i = 0, j = 0; i < ARRAY_SIZE(page_flag_names); i++) { bit = (flags >> i) & 1; if (!page_flag_names[i]) { if (bit) fprintf(stderr, "unkown flag bit %d\n", i); continue; } buf[j++] = bit ? page_flag_names[i][0] : '_'; } return buf; } char *page_flag_longname(uint64_t flags) { int i, n; static char buf[1024]; for (i = 0, n = 0; i < ARRAY_SIZE(page_flag_names); i++) { if (!page_flag_names[i]) continue; if ((flags >> i) & 1) n += snprintf(buf + n, sizeof(buf) - n, "%s,", page_flag_names[i] + 2); } if (n) n--; buf[n] = '\0'; return buf; } static unsigned long nr_pages; static uint64_t kpageflags[KPF_BYTES * (1<<20)]; unsigned long collect_page_count() { unsigned long n; unsigned long i; uint64_t flags; int fd; fd = open(PROC_KPAGEFLAGS, O_RDONLY); if (fd < 0) { perror(PROC_KPAGEFLAGS); exit(1); } while (1) { n = read(fd, kpageflags, sizeof(kpageflags)); if (n == 0) break; if (n < 0) { perror(PROC_KPAGEFLAGS); exit(2); } if (n % KPF_BYTES != 0) { fprintf(stderr, "partial read: %lu bytes\n", n); exit(3); } n = n / KPF_BYTES; for (i = 0; i < n; i++) { flags = kpageflags[i]; page_count[hash_index(flags)]++; } nr_pages += n; } close(fd); } void show_page_count() { int i; printf(" flags\tpage-count MB" " symbolic-flags\t\t\tlong-symbolic-flags\n"); for (i = 0; i < ARRAY_SIZE(page_count); i++) { if (page_count[i]) printf("0x%012lx\t%10lu %8lu %s\t%s\n", page_flags[i], page_count[i], pages2mb(page_count[i]), page_flag_name(page_flags[i]), page_flag_longname(page_flags[i])); } printf(" total\t%10lu %8lu\n", nr_pages, pages2mb(nr_pages)); } int main(int argc, char *argv[]) { collect_page_count(); show_page_count(); return 0; } [-- Attachment #4: page-areas.c --] [-- Type: text/x-csrc, Size: 1495 bytes --] #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdint.h> #include <sys/types.h> #include <sys/errno.h> #include <sys/fcntl.h> #include "pagemap.h" static void add_index(unsigned long index) { static unsigned long offset, len; if (index == offset + len) len++; else { if (len) printf("%10lu %8lu %8luKB\n", offset, len, pages2kb(len)); offset = index; len = 1; } } static void usage(const char *prog) { printf("Usage: %s page_flags\n", prog); } static uint64_t kpageflags[KPF_BYTES * (1<<20)]; int main(int argc, char *argv[]) { uint64_t match_flags; int match_exact; unsigned long n; unsigned long i; char *p; int fd; if (argc < 2) { usage(argv[0]); exit(1); } match_exact = 0; p = argv[1]; if (p[0] == '=') { match_exact = 1; p++; } match_flags = strtol(p, 0, 16); fd = open(PROC_KPAGEFLAGS, O_RDONLY); if (fd < 0) { perror(PROC_KPAGEFLAGS); exit(1); } while (1) { n = read(fd, kpageflags, sizeof(kpageflags)); if (n == 0) break; if (n < 0) { perror(PROC_KPAGEFLAGS); exit(2); } if (n % KPF_BYTES != 0) { fprintf(stderr, "%s: partial read: %lu bytes\n", argv[0], n); exit(3); } n = n / KPF_BYTES; printf(" offset len KB\n"); for (i = 0; i < n; i++) { if (!match_exact && ((kpageflags[i] & match_flags) == match_flags) || (match_exact && kpageflags[i] == match_flags)) add_index(i); } } add_index(0); /* flush the stored range */ return 0; } [-- Attachment #5: Makefile --] [-- Type: text/plain, Size: 169 bytes --] BINS = page-types page-areas all: $(BINS) page-types: page-types.c pagemap.h gcc -g -o $@ $< page-areas: page-areas.c pagemap.h gcc -g -o $@ $< clean: rm $(BINS) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 6:54 ` KOSAKI Motohiro @ 2009-04-14 7:22 ` Wu Fengguang -1 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-14 7:22 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andrew Morton, Andi Kleen, LKML, linux-mm On Tue, Apr 14, 2009 at 02:54:40PM +0800, KOSAKI Motohiro wrote: > Hi > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > Export the following page flags in /proc/kpageflags, > > > > just in case they will be useful to someone: > > > > > > > > - PG_swapcache > > > > - PG_swapbacked > > > > - PG_mappedtodisk > > > > - PG_reserved > > > > - PG_private > > > > - PG_private_2 > > > > - PG_owner_priv_1 > > > > > > > > - PG_head > > > > - PG_tail > > > > - PG_compound > > > > > > > > - PG_unevictable > > > > - PG_mlocked > > > > > > > > - PG_poison > > > > > > Sorry, NAK this. > > > We shouldn't expose internal flags. please choice useful flags only. > > > > OK. So are there anyone interested in any of these flags? Thanks! > > > > My rational to export most page flags is that hopefully they could > > help debugging kernel at some random situations.. > > I think, > > > > > - PG_mappedtodisk > > > > - PG_reserved > > > > - PG_private > > > > - PG_private_2 > > > > - PG_owner_priv_1 > > > > > > > > - PG_head > > > > - PG_tail > > > > - PG_unevictable > > > > - PG_mlocked How about including PG_unevictable/PG_mlocked? They shall be meaningful to administrators. > this 9 flags shouldn't exported. > I can't imazine administrator use what purpose those flags. > > > > - PG_swapcache > > > > - PG_swapbacked > > > > - PG_poison > > > > - PG_compound > > I can agree this 4 flags. > However pagemap lack's hugepage considering. > if PG_compound exporting, we need more work. You mean to fold PG_head/PG_tail into PG_COMPOUND? Yes, that's a good simplification for end users. > > > > > > Also add the following two pseudo page flags: > > > > > > > > - PG_MMAP: whether the page is memory mapped > > hm, I can agree it. > > > > > > - PG_NOPAGE: whether the page is present > > PM_NOT_PRESENT isn't enough? That would not be usable if you are going to do a system wide scan. PG_NOPAGE could help differentiate the 'no page' case from 'no flags' case. However PG_NOPAGE is more about the last resort. The system wide scan can be made much more efficient if we know the exact memory layouts. Thanks, Fengguang > > > > > > > > This increases the total number of exported page flags to 25. > > > > > > > > Cc: Andi Kleen <andi@firstfloor.org> > > > > Cc: Matt Mackall <mpm@selenic.com> > > > > Cc: Alexey Dobriyan <adobriyan@gmail.com> > > > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > > > > --- > > > > fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- > > > > 1 file changed, 81 insertions(+), 31 deletions(-) > > > > > > > > --- mm.orig/fs/proc/page.c > > > > +++ mm/fs/proc/page.c > > > > @@ -68,20 +68,86 @@ static const struct file_operations proc > > > > > > > > /* These macros are used to decouple internal flags from exported ones */ > > > > > > > > -#define KPF_LOCKED 0 > > > > -#define KPF_ERROR 1 > > > > -#define KPF_REFERENCED 2 > > > > -#define KPF_UPTODATE 3 > > > > -#define KPF_DIRTY 4 > > > > -#define KPF_LRU 5 > > > > -#define KPF_ACTIVE 6 > > > > -#define KPF_SLAB 7 > > > > -#define KPF_WRITEBACK 8 > > > > -#define KPF_RECLAIM 9 > > > > -#define KPF_BUDDY 10 > > > > +enum { > > > > + KPF_LOCKED, /* 0 */ > > > > + KPF_ERROR, /* 1 */ > > > > + KPF_REFERENCED, /* 2 */ > > > > + KPF_UPTODATE, /* 3 */ > > > > + KPF_DIRTY, /* 4 */ > > > > + KPF_LRU, /* 5 */ > > > > + KPF_ACTIVE, /* 6 */ > > > > + KPF_SLAB, /* 7 */ > > > > + KPF_WRITEBACK, /* 8 */ > > > > + KPF_RECLAIM, /* 9 */ > > > > + KPF_BUDDY, /* 10 */ > > > > + KPF_MMAP, /* 11 */ > > > > + KPF_SWAPCACHE, /* 12 */ > > > > + KPF_SWAPBACKED, /* 13 */ > > > > + KPF_MAPPEDTODISK, /* 14 */ > > > > + KPF_RESERVED, /* 15 */ > > > > + KPF_PRIVATE, /* 16 */ > > > > + KPF_PRIVATE2, /* 17 */ > > > > + KPF_OWNER_PRIVATE, /* 18 */ > > > > + KPF_COMPOUND_HEAD, /* 19 */ > > > > + KPF_COMPOUND_TAIL, /* 20 */ > > > > + KPF_UNEVICTABLE, /* 21 */ > > > > + KPF_MLOCKED, /* 22 */ > > > > + KPF_POISON, /* 23 */ > > > > + KPF_NOPAGE, /* 24 */ > > > > + KPF_NUM > > > > +}; > > > > > > this is userland export value. then enum is wrong idea. > > > explicit name-number relationship is better. it prevent unintetional > > > ABI break. > > > > Right, that's the reason I add the /* number */ comments. > > Anyway, it would be better to use explicit #defines. > > > > Thanks, > > Fengguang > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 7:22 ` Wu Fengguang 0 siblings, 0 replies; 44+ messages in thread From: Wu Fengguang @ 2009-04-14 7:22 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andrew Morton, Andi Kleen, LKML, linux-mm On Tue, Apr 14, 2009 at 02:54:40PM +0800, KOSAKI Motohiro wrote: > Hi > > > On Tue, Apr 14, 2009 at 12:37:10PM +0800, KOSAKI Motohiro wrote: > > > > Export the following page flags in /proc/kpageflags, > > > > just in case they will be useful to someone: > > > > > > > > - PG_swapcache > > > > - PG_swapbacked > > > > - PG_mappedtodisk > > > > - PG_reserved > > > > - PG_private > > > > - PG_private_2 > > > > - PG_owner_priv_1 > > > > > > > > - PG_head > > > > - PG_tail > > > > - PG_compound > > > > > > > > - PG_unevictable > > > > - PG_mlocked > > > > > > > > - PG_poison > > > > > > Sorry, NAK this. > > > We shouldn't expose internal flags. please choice useful flags only. > > > > OK. So are there anyone interested in any of these flags? Thanks! > > > > My rational to export most page flags is that hopefully they could > > help debugging kernel at some random situations.. > > I think, > > > > > - PG_mappedtodisk > > > > - PG_reserved > > > > - PG_private > > > > - PG_private_2 > > > > - PG_owner_priv_1 > > > > > > > > - PG_head > > > > - PG_tail > > > > - PG_unevictable > > > > - PG_mlocked How about including PG_unevictable/PG_mlocked? They shall be meaningful to administrators. > this 9 flags shouldn't exported. > I can't imazine administrator use what purpose those flags. > > > > - PG_swapcache > > > > - PG_swapbacked > > > > - PG_poison > > > > - PG_compound > > I can agree this 4 flags. > However pagemap lack's hugepage considering. > if PG_compound exporting, we need more work. You mean to fold PG_head/PG_tail into PG_COMPOUND? Yes, that's a good simplification for end users. > > > > > > Also add the following two pseudo page flags: > > > > > > > > - PG_MMAP: whether the page is memory mapped > > hm, I can agree it. > > > > > > - PG_NOPAGE: whether the page is present > > PM_NOT_PRESENT isn't enough? That would not be usable if you are going to do a system wide scan. PG_NOPAGE could help differentiate the 'no page' case from 'no flags' case. However PG_NOPAGE is more about the last resort. The system wide scan can be made much more efficient if we know the exact memory layouts. Thanks, Fengguang > > > > > > > > This increases the total number of exported page flags to 25. > > > > > > > > Cc: Andi Kleen <andi@firstfloor.org> > > > > Cc: Matt Mackall <mpm@selenic.com> > > > > Cc: Alexey Dobriyan <adobriyan@gmail.com> > > > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> > > > > --- > > > > fs/proc/page.c | 112 +++++++++++++++++++++++++++++++++-------------- > > > > 1 file changed, 81 insertions(+), 31 deletions(-) > > > > > > > > --- mm.orig/fs/proc/page.c > > > > +++ mm/fs/proc/page.c > > > > @@ -68,20 +68,86 @@ static const struct file_operations proc > > > > > > > > /* These macros are used to decouple internal flags from exported ones */ > > > > > > > > -#define KPF_LOCKED 0 > > > > -#define KPF_ERROR 1 > > > > -#define KPF_REFERENCED 2 > > > > -#define KPF_UPTODATE 3 > > > > -#define KPF_DIRTY 4 > > > > -#define KPF_LRU 5 > > > > -#define KPF_ACTIVE 6 > > > > -#define KPF_SLAB 7 > > > > -#define KPF_WRITEBACK 8 > > > > -#define KPF_RECLAIM 9 > > > > -#define KPF_BUDDY 10 > > > > +enum { > > > > + KPF_LOCKED, /* 0 */ > > > > + KPF_ERROR, /* 1 */ > > > > + KPF_REFERENCED, /* 2 */ > > > > + KPF_UPTODATE, /* 3 */ > > > > + KPF_DIRTY, /* 4 */ > > > > + KPF_LRU, /* 5 */ > > > > + KPF_ACTIVE, /* 6 */ > > > > + KPF_SLAB, /* 7 */ > > > > + KPF_WRITEBACK, /* 8 */ > > > > + KPF_RECLAIM, /* 9 */ > > > > + KPF_BUDDY, /* 10 */ > > > > + KPF_MMAP, /* 11 */ > > > > + KPF_SWAPCACHE, /* 12 */ > > > > + KPF_SWAPBACKED, /* 13 */ > > > > + KPF_MAPPEDTODISK, /* 14 */ > > > > + KPF_RESERVED, /* 15 */ > > > > + KPF_PRIVATE, /* 16 */ > > > > + KPF_PRIVATE2, /* 17 */ > > > > + KPF_OWNER_PRIVATE, /* 18 */ > > > > + KPF_COMPOUND_HEAD, /* 19 */ > > > > + KPF_COMPOUND_TAIL, /* 20 */ > > > > + KPF_UNEVICTABLE, /* 21 */ > > > > + KPF_MLOCKED, /* 22 */ > > > > + KPF_POISON, /* 23 */ > > > > + KPF_NOPAGE, /* 24 */ > > > > + KPF_NUM > > > > +}; > > > > > > this is userland export value. then enum is wrong idea. > > > explicit name-number relationship is better. it prevent unintetional > > > ABI break. > > > > Right, that's the reason I add the /* number */ comments. > > Anyway, it would be better to use explicit #defines. > > > > Thanks, > > Fengguang > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags 2009-04-14 7:22 ` Wu Fengguang @ 2009-04-14 7:42 ` KOSAKI Motohiro -1 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-14 7:42 UTC (permalink / raw) To: Wu Fengguang; +Cc: kosaki.motohiro, Andrew Morton, Andi Kleen, LKML, linux-mm > > > > > - PG_unevictable > > > > > - PG_mlocked > > How about including PG_unevictable/PG_mlocked? > They shall be meaningful to administrators. I explained another mail. please see it. > > this 9 flags shouldn't exported. > > I can't imazine administrator use what purpose those flags. > > > > > > - PG_swapcache > > > > > - PG_swapbacked > > > > > - PG_poison > > > > > - PG_compound > > > > I can agree this 4 flags. > > However pagemap lack's hugepage considering. > > if PG_compound exporting, we need more work. > > You mean to fold PG_head/PG_tail into PG_COMPOUND? > Yes, that's a good simplification for end users. Yes, I agree. > > > > > - PG_NOPAGE: whether the page is present > > > > PM_NOT_PRESENT isn't enough? > > That would not be usable if you are going to do a system wide scan. > PG_NOPAGE could help differentiate the 'no page' case from 'no flags' > case. > > However PG_NOPAGE is more about the last resort. The system wide scan > can be made much more efficient if we know the exact memory layouts. Yup :) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags @ 2009-04-14 7:42 ` KOSAKI Motohiro 0 siblings, 0 replies; 44+ messages in thread From: KOSAKI Motohiro @ 2009-04-14 7:42 UTC (permalink / raw) To: Wu Fengguang; +Cc: kosaki.motohiro, Andrew Morton, Andi Kleen, LKML, linux-mm > > > > > - PG_unevictable > > > > > - PG_mlocked > > How about including PG_unevictable/PG_mlocked? > They shall be meaningful to administrators. I explained another mail. please see it. > > this 9 flags shouldn't exported. > > I can't imazine administrator use what purpose those flags. > > > > > > - PG_swapcache > > > > > - PG_swapbacked > > > > > - PG_poison > > > > > - PG_compound > > > > I can agree this 4 flags. > > However pagemap lack's hugepage considering. > > if PG_compound exporting, we need more work. > > You mean to fold PG_head/PG_tail into PG_COMPOUND? > Yes, that's a good simplification for end users. Yes, I agree. > > > > > - PG_NOPAGE: whether the page is present > > > > PM_NOT_PRESENT isn't enough? > > That would not be usable if you are going to do a system wide scan. > PG_NOPAGE could help differentiate the 'no page' case from 'no flags' > case. > > However PG_NOPAGE is more about the last resort. The system wide scan > can be made much more efficient if we know the exact memory layouts. Yup :) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2009-04-25 1:59 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-14 4:22 [RFC][PATCH] proc: export more page flags in /proc/kpageflags Wu Fengguang 2009-04-14 4:22 ` Wu Fengguang 2009-04-14 4:36 ` Wu Fengguang 2009-04-14 4:37 ` KOSAKI Motohiro 2009-04-14 4:37 ` KOSAKI Motohiro 2009-04-14 6:41 ` Wu Fengguang 2009-04-14 6:41 ` Wu Fengguang 2009-04-14 6:54 ` KOSAKI Motohiro 2009-04-14 6:54 ` KOSAKI Motohiro 2009-04-14 7:11 ` Andi Kleen 2009-04-14 7:11 ` Andi Kleen 2009-04-14 7:17 ` KOSAKI Motohiro 2009-04-14 7:17 ` KOSAKI Motohiro 2009-04-15 13:18 ` Wu Fengguang 2009-04-15 13:18 ` Wu Fengguang 2009-04-15 13:57 ` Andi Kleen 2009-04-15 13:57 ` Andi Kleen 2009-04-16 2:41 ` Wu Fengguang 2009-04-16 2:41 ` Wu Fengguang 2009-04-16 3:54 ` Andi Kleen 2009-04-16 3:54 ` Andi Kleen 2009-04-16 4:43 ` Wu Fengguang 2009-04-16 4:43 ` Wu Fengguang 2009-04-16 2:26 ` KOSAKI Motohiro 2009-04-16 2:26 ` KOSAKI Motohiro 2009-04-16 3:49 ` Wu Fengguang 2009-04-16 3:49 ` Wu Fengguang 2009-04-16 6:30 ` Wu Fengguang 2009-04-16 6:30 ` Wu Fengguang 2009-04-23 2:26 ` [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3) Wu Fengguang 2009-04-23 2:26 ` Wu Fengguang 2009-04-23 7:48 ` Andi Kleen 2009-04-23 7:48 ` Andi Kleen 2009-04-23 8:10 ` Wu Fengguang 2009-04-23 8:10 ` Wu Fengguang 2009-04-23 8:54 ` Andi Kleen 2009-04-23 8:54 ` Andi Kleen 2009-04-23 11:21 ` Wu Fengguang 2009-04-23 11:21 ` Wu Fengguang 2009-04-25 1:59 ` Wu Fengguang 2009-04-14 7:22 ` [RFC][PATCH] proc: export more page flags in /proc/kpageflags Wu Fengguang 2009-04-14 7:22 ` Wu Fengguang 2009-04-14 7:42 ` KOSAKI Motohiro 2009-04-14 7:42 ` KOSAKI Motohiro
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.