lkml.org 
[lkml]   [2009]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] proc: export more page flags in /proc/kpageflags
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



\
 
 \ /
  Last update: 2009-04-16 05:53    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site