Re: [rfc 03/10] Pageflags: Convert to the use of new macros

[Mel Gorman]

On (03/03/08 10:03), Christoph Lameter didst pronounce:
> On Mon, 3 Mar 2008, Mel Gorman wrote:
> 
> > > +PAGEFLAG(Checked, owner_priv_1)		/* Used by some filesystems */
> > > +PAGEFLAG(Pinned, owner_priv_1)		/* Xen pinned pagetable */
> > 
> > This is what I was on about earlier with some flag comments being in a
> > separate place. Someone grepping for PG_pinned to see what it is for
> > would have a bad day.
> 
> These aliases seem to be not a good thing. PG_pinned etc are never used. 
> Greeping for SetPagePinned etc may be better.
> 

I guess it's a question of taste. I would prefer all the flags that
exist to be named in the one place so all the comments are there.
However, functionally it's identical no harm.

> > > +#ifdef CONFIG_HIGHMEM
> > > +#define PageHighMem(page)	is_highmem(page_zone(page))
> > > +#else
> > > +#define PageHighMem(page)	0 /* needed to optimize away at compile time */
> > > +#endif
> > > +
> > 
> > Seems to be a tiny inconsistency here. PageSwapCache below is a static
> > inline returning 0 that you fixed up as part of the shuffling where as
> > PageHighMem is #defined to 0. Care to fix it up too?
> 
> Ok.
> 
> > > -#define SetPagePrivate(page)	set_bit(PG_private, &(page)->flags)
> > > -#define ClearPagePrivate(page)	clear_bit(PG_private, &(page)->flags)
> > > -#define PagePrivate(page)	test_bit(PG_private, &(page)->flags)
> > > -#define __SetPagePrivate(page)  __set_bit(PG_private, &(page)->flags)
> > > -#define __ClearPagePrivate(page) __clear_bit(PG_private, &(page)->flags)
> > > +static inline void set_page_writeback(struct page *page)
> > > +{
> > > +	test_set_page_writeback(page);
> > > +}
> > 
> > It's been around for ages and unrelated to your patch series but it
> > looks odd that set_page_writeback() is simply a function alias that
> > ignores return values :/
> 
> Yes its strange. Is there a set_page_writeback function?
> 

Other than this inline, none that I spotted. It has a number of call-sites
though so I guess the intention was to implicitly document that ignoring
the return value was deliberate. Might as well leave it.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/