Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755547AbZD1JPG (ORCPT ); Tue, 28 Apr 2009 05:15:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754650AbZD1JOx (ORCPT ); Tue, 28 Apr 2009 05:14:53 -0400 Received: from mga03.intel.com ([143.182.124.21]:12698 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754342AbZD1JOw (ORCPT ); Tue, 28 Apr 2009 05:14:52 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,259,1239001200"; d="scan'208";a="136704411" Date: Tue, 28 Apr 2009 16:33:20 +0800 From: Wu Fengguang To: Ingo Molnar Cc: Steven Rostedt , =?utf-8?B?RnLDqWTDqXJpYw==?= Weisbecker , Larry Woodman , Peter Zijlstra , Pekka Enberg , Eduard - Gabriel Munteanu , Andrew Morton , LKML , KOSAKI Motohiro , Andi Kleen , Matt Mackall , Alexey Dobriyan , "linux-mm@kvack.org" Subject: Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags Message-ID: <20090428083320.GB17038@localhost> References: <20090428010907.912554629@intel.com> <20090428014920.769723618@intel.com> <20090428065507.GA2024@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090428065507.GA2024@elte.hu> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5920 Lines: 142 On Tue, Apr 28, 2009 at 08:55:07AM +0200, Ingo Molnar wrote: > > * Wu Fengguang wrote: > > > 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_HWPOISON 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: mask out the overloaded PG_readahead > > - compound flags: only export huge/gigantic pages > > > > 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 491174 1918 ____________________________ > > 0x000000000020 1 0 _____l______________________ lru > > 0x000000000028 2543 9 ___U_l______________________ uptodate,lru > > 0x00000000002c 5288 20 __RU_l______________________ referenced,uptodate,lru > > 0x000000004060 1 0 _____lA_______b_____________ lru,active,swapbacked > > I think i have to NAK this kind of ad-hoc instrumentation of kernel > internals and statistics until we clear up why such instrumentation > measures are being accepted into the MM while other, more dynamic > and more flexible MM instrumentation are being resisted by Andrew. An unexpected NAK - to throw away an orange because we are to have an apple? ;-) Anyway here are the missing rationals. 1) FAST It takes merely 0.2s to scan 4GB pages: ./page-types 0.02s user 0.20s system 99% cpu 0.216 total 2) SIMPLE /proc/kpageflags will be a *long standing* hack we have to live with - it was originally introduced by Matt to do shared memory accounting and a facility to analyze applications' memory consumptions, with the hope it will also help kernel developers someday. So why not extend and embrace it, in a straightforward way? 3) USE CASES I have/will take advantage of the above page-types command in a number ways: - to help track down memory leak (the recent trace/ring_buffer.c case) - to estimate the system wide readahead miss ratio - Andi want to examine the major page types in different workloads (for the hwpoison work) - Me too, for fun of learning: read/write/lock/whatever a lot of pages and examine their flags, to get an idea of some random kernel behaviors. (the dynamic tracing tools can be more helpful, as a different view) 4) COMPLEMENTARITY In some cases the dynamic tracing tool is not enough (or too complex) to rebuild the current status view. I myself have a dynamic readahead tracing tool(very useful!). At the same time I also use readahead accounting numbers, and the /proc/filecache tool(frequently!), and the above page-types tool. I simply need them all - they are handy for different cases. Thanks, Fengguang > The above type of condensed information can be built out of dynamic > trace data too - and much more. Being able to track page state > transitions is very valuable when debugging VM problems. One such > 'view' of trace data would be a summary histogram like above. > > ( done after a "echo 3 > /proc/sys/vm/drop_caches" to make sure all > interesting pages have been re-established and their state is > present in the trace. ) > > The SLAB code already has such a facility, kmemtrace: it's very > useful and successful in visualizing complex SLAB details, both > dynamically and statically. > > I think the same general approach should be used for the page > allocator too (and for the page cache and some other struct page > based caches): the life-time of an object should be followed. If we > capture the important details we capture the big picture too. Pekka > already sent an RFC patch to extend kmemtrace in such a fashion. Why > is that more useful method not being pursued? > > By extending upon the (existing) /proc/kpageflags hack a usecase is > taken away from the tracing based solution and a needless overlap is > created - and that's not particularly helpful IMHO. We now have all > the facilities upstream that allow us to do intelligent > instrumentation - we should make use of them. > > Ingo > > -- > 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: email@kvack.org -- 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/