public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russ Anderson <rja@sgi.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Tony Luck <tony.luck@intel.com>,
	Christoph Lameter <clameter@sgi.com>
Subject: Re: [PATCH 1/3] mm: Minor clean-up of page flags in mm/page_alloc.c v4
Date: Wed, 14 May 2008 16:30:02 -0500	[thread overview]
Message-ID: <20080514213001.GA13702@sgi.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0805141321020.3019@woody.linux-foundation.org>

On Wed, May 14, 2008 at 01:28:53PM -0700, Linus Torvalds wrote:
> On Tue, 13 May 2008, Russ Anderson wrote:
> >
> > Minor source code cleanup of page flags in mm/page_alloc.c.  
> 
> Could we (a) make the naming reflect the *use* rather than the flags 
> involved and (b) perhaps add a comment about that use at the point of 
> definition?

Yes, will do.  The reason for the cleanup is the following patch
defines PG_memerror, but only on configs with extended page flags.
So checking them in page_alloc.c would require adding #ifdef, which
would be rather ugly.  Moving the definitions into page-flags.h
allows the #ifdef to be in the header file rather than the C code.

>From page.discard.v4:
+#ifdef CONFIG_PAGEFLAGS_EXTENDED
+PAGEFLAG(MemError, memerror)
+#define        PAGE_FLAGS      (PAGE_FLAGS_BASE | 1UL << PG_memerror)
+#else
+PAGEFLAG_FALSE(MemError)
+#define        PAGE_FLAGS      (PAGE_FLAGS_BASE)
+#endif

 
> > @@ -237,16 +237,7 @@ static void bad_page(struct page *page)
> >  	printk(KERN_EMERG "Trying to fix it up, but a reboot is needed\n"
> >  		KERN_EMERG "Backtrace:\n");
> >  	dump_stack();
> > -	page->flags &= ~(1 << PG_lru	|
> > -			1 << PG_private |
> > -			1 << PG_locked	|
> > -			1 << PG_active	|
> > -			1 << PG_dirty	|
> > -			1 << PG_reclaim |
> > -			1 << PG_slab    |
> > -			1 << PG_swapcache |
> > -			1 << PG_writeback |
> > -			1 << PG_buddy );
> > +	page->flags &= ~(PAGE_FLAGS_RECLAIM);
> 
> Because here I'm now otherwise looking at the code, and I wonder
>  - why the extra odd parenthesis?
>  - what does PAGE_FLAG_RECLAIM mean?
> 
> and it would be much nicer (I think) if the mask was instead called 
> something that reflected what it was all about, ie something along the 
> lines of PAGE_FLAG_CLEAR_WHEN_BAD instead.

I'll make those changes.

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@sgi.com

      reply	other threads:[~2008-05-14 21:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-13 23:02 [PATCH 1/3] mm: Minor clean-up of page flags in mm/page_alloc.c v4 Russ Anderson
2008-05-14 20:28 ` Linus Torvalds
2008-05-14 21:30   ` Russ Anderson [this message]

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=20080514213001.GA13702@sgi.com \
    --to=rja@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox