LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-kernel@vger.kernel.org, Nick Piggin <npiggin@suse.de>,
Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
apw@shadowen.org, linux-mm@kback.org
Subject: Re: [rfc 03/10] Pageflags: Convert to the use of new macros
Date: Fri, 7 Mar 2008 11:13:55 +0000 [thread overview]
Message-ID: <20080307111355.GB26229@csn.ul.ie> (raw)
In-Reply-To: <Pine.LNX.4.64.0803031001440.6010@schroedinger.engr.sgi.com>
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
next prev parent reply other threads:[~2008-03-07 11:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-01 4:05 [rfc 00/10] [RFC] Page flags: Saving some, making handling easier etc Christoph Lameter
2008-03-01 4:05 ` [rfc 01/10] Pageflags: Use an enum for the flags Christoph Lameter
2008-03-03 10:09 ` Mel Gorman
2008-03-01 4:05 ` [rfc 02/10] Pageflags: Introduce macros to generate page flag functions Christoph Lameter
2008-03-01 4:05 ` [rfc 03/10] Pageflags: Convert to the use of new macros Christoph Lameter
2008-03-03 10:24 ` Mel Gorman
2008-03-03 18:03 ` Christoph Lameter
2008-03-07 11:13 ` Mel Gorman [this message]
2008-03-01 4:05 ` [rfc 04/10] Pageflags: Eliminate PG_readahead Christoph Lameter
2008-03-01 4:05 ` [rfc 05/10] Sparsemem: Vmemmap does not need section bits Christoph Lameter
2008-03-01 4:05 ` [rfc 06/10] Kbuild: Create a way to create preprocessor constants from C expressions Christoph Lameter
2008-03-01 4:05 ` [rfc 07/10] Pageflags: Get rid of FLAGS_RESERVED Christoph Lameter
2008-03-01 16:26 ` Rik van Riel
2008-03-03 17:57 ` Christoph Lameter
2008-03-01 4:05 ` [rfc 08/10] Export NR_MAX_ZONES to the preprocessor Christoph Lameter
2008-03-01 4:05 ` [rfc 09/10] Get rid of __ZONE_COUNT Christoph Lameter
2008-03-01 4:05 ` [rfc 10/10] Pageflags land grab Christoph Lameter
2008-03-01 17:21 ` Rik van Riel
2008-03-04 0:04 [rfc 00/10] [Patch] Page flags: Cleanup, reorg and introduce 5 new flags Christoph Lameter
2008-03-04 0:04 ` [rfc 03/10] Pageflags: Convert to the use of new macros Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080307111355.GB26229@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kback.org \
--cc=npiggin@suse.de \
--cc=riel@redhat.com \
--subject='Re: [rfc 03/10] Pageflags: Convert to the use of new macros' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).