lkml.org 
[lkml]   [2009]   [Apr]   [23]   [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 (take 3)
    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


    \
     
     \ /
      Last update: 2009-04-23 10:13    [W:3.482 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site