All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags
Date: Thu, 16 Apr 2009 14:30:24 +0800	[thread overview]
Message-ID: <20090416063024.GA5803@localhost> (raw)
In-Reply-To: <20090416034918.GB20162@localhost>

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

WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags
Date: Thu, 16 Apr 2009 14:30:24 +0800	[thread overview]
Message-ID: <20090416063024.GA5803@localhost> (raw)
In-Reply-To: <20090416034918.GB20162@localhost>

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>

  reply	other threads:[~2009-04-16  6:31 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090416063024.GA5803@localhost \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.