[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0906090907110.17452@gandalf.stny.rr.com>
Date: Tue, 9 Jun 2009 09:08:05 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Mel Gorman <mel@....ul.ie>
cc: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Minchan Kim <minchan.kim@...il.com>,
Christoph Hellwig <hch@...radead.org>,
Rik van Riel <riel@...hat.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Frederic Weisbecker <fweisbec@...il.com>,
Theodore Tso <tytso@....edu>,
Mathieu Desnoyers <compudj@...stal.dyndns.org>,
Lai Jiangshan <laijs@...fujitsu.com>,
Zhaolei <zhaolei@...fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Jason Baron <jbaron@...hat.com>,
Jiaying Zhang <jiayingz@...gle.com>
Subject: Re: [RFC PATCH 5/5] tracing/events: modify kmem print to new
format
On Tue, 9 Jun 2009, Mel Gorman wrote:
> On Tue, Jun 09, 2009 at 09:12:42AM +0200, Peter Zijlstra wrote:
> > On Mon, 2009-06-08 at 21:45 -0400, Steven Rostedt wrote:
> >
> > > +#define show_gfp_flags(end...) \
> > > + "0=GFP_NOWAIT," \
> > > + "0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s," \
> > > + "0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s," \
> > > + "0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s," \
> > > + "0x%lx=%s,0x%lx=%s>" end , \
> > > + (unsigned long)GFP_HIGHUSER_MOVABLE, "GFP_HIGHUSER_MOVABLE", \
> > > + (unsigned long)GFP_HIGHUSER, "GFP_HIGHUSER", \
> > > + (unsigned long)GFP_USER, "GFP_USER", \
> > > + (unsigned long)GFP_TEMPORARY, "GFP_TEMPORARY", \
> > > + (unsigned long)GFP_KERNEL, "GFP_KERNEL", \
> > > + (unsigned long)GFP_NOFS, "GFP_NOFS", \
> > > + (unsigned long)GFP_ATOMIC, "GFP_ATOMIC", \
> > > + (unsigned long)GFP_NOIO, "GFP_NOIO", \
> > > + (unsigned long)__GFP_HIGH, "GFP_HIGH", \
> > > + (unsigned long)__GFP_WAIT, "GFP_WAIT", \
> > > + (unsigned long)__GFP_IO, "GFP_IO", \
> > > + (unsigned long)__GFP_COLD, "GFP_COLD", \
> > > + (unsigned long)__GFP_NOWARN, "GFP_NOWARN", \
> > > + (unsigned long)__GFP_REPEAT, "GFP_REPEAT", \
> > > + (unsigned long)__GFP_NOFAIL, "GFP_NOFAIL", \
> > > + (unsigned long)__GFP_NORETRY, "GFP_NORETRY", \
> > > + (unsigned long)__GFP_COMP, "GFP_COMP", \
> > > + (unsigned long)__GFP_ZERO, "GFP_ZERO", \
> > > + (unsigned long)__GFP_NOMEMALLOC, "GFP_NOMEMALLOC", \
> > > + (unsigned long)__GFP_HARDWALL, "GFP_HARDWALL", \
> > > + (unsigned long)__GFP_THISNODE, "GFP_THISNODE", \
> > > + (unsigned long)__GFP_RECLAIMABLE, "GFP_RECLAIMABLE", \
> > > + (unsigned long)__GFP_MOVABLE, "GFP_MOVABLE"
> >
> > Just curious, how unhappy does stuff become when we add a __GFP_ flag
> > and forget to extend this table?
> >
>
> If it's the same behaviour as what I was looking at yesterday, it prints
> the remaining flags it doesn't recognise as the number.
>
> GFP_KERNEL|__GFP_DMA got outputted as |GFP_KERNEL|0x1|
Yep, that is what would happen here too.
Any comments on this approach? I'll go ahead and start fixing it up more
(handling all the memory freeing on errors) and get it ready to push out.
-- Steve
--
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/
Powered by blists - more mailing lists