Re: [RFC PATCH 5/5] tracing/events: modify kmem print to newformat

[Steven Rostedt]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/