linux-kernel - Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Apr 2009 16:10:47 +0800
From:	Wu Fengguang <fengguang.wu@...el.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/