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
prev parent 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