[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0812012349330.18893@blonde.anvils>
Date: Mon, 1 Dec 2008 23:50:33 +0000 (GMT)
From: Hugh Dickins <hugh@...itas.com>
To: Christoph Lameter <cl@...ux-foundation.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Russ Anderson <rja@....com>,
Nick Piggin <nickpiggin@...oo.com.au>,
Dave Jones <davej@...hat.com>,
Arjan van de Ven <arjan@...radead.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 1/8] badpage: simplify page_alloc flag check+clear
On Mon, 1 Dec 2008, Christoph Lameter wrote:
> On Mon, 1 Dec 2008, Hugh Dickins wrote:
> > /*
> > * Flags checked when a page is freed. Pages being freed should not have
> > * these flags set. It they are, there is a problem.
> > */
> > -#define PAGE_FLAGS_CHECK_AT_FREE (PAGE_FLAGS | 1 << PG_reserved)
> > +#define PAGE_FLAGS_CHECK_AT_FREE \
> > + (1 << PG_lru | 1 << PG_private | 1 << PG_locked | \
> > + 1 << PG_buddy | 1 << PG_writeback | 1 << PG_reserved | \
> > + 1 << PG_slab | 1 << PG_swapcache | 1 << PG_active | \
> > + __PG_UNEVICTABLE | __PG_MLOCKED)
>
> Rename this to PAGE_FLAGS_CLEAR_WHEN_FREE?
No, that's a list of just the ones it's checking at free;
it then (with this patch) goes on to clear all of them.
>
> > + * Pages being prepped should not have any flags set. It they are set,
> > + * there has been a kernel bug or struct page corruption.
> > */
> > -#define PAGE_FLAGS_CHECK_AT_PREP (PAGE_FLAGS | \
> > - 1 << PG_reserved | 1 << PG_dirty | 1 << PG_swapbacked)
> > +#define PAGE_FLAGS_CHECK_AT_PREP ((1 << NR_PAGEFLAGS) - 1)
>
> These are all the bits. Can we get rid of this definition?
PAGE_FLAGS_CHECK_AT_PREP may not be the best name for it now;
but I do think we need a definition for it, and I'm not sure
that it will remain "all the page flags".
As it was, I just took the existing name, and then included every
flag in it. I'd love to include the empty space, if any, up as
far as the mmzone bits - is there a convenient way to do that?
It could as well be called PAGE_FLAGS_CLEAR_AT_FREE. I'm not
sure that it's necessarily the same as all the flags - in fact,
I was rather surprised that the patch booted first time, I was
expecting to find that I'd overlooked some special cases.
I meant to, but didn't, look at Martin's guest page hinting, might
that be defining page flags set even across the free/alloc gap?
Cc'ed Martin now, no need for him to answer, but let's at least
warn him of this patch, something he might need to change with his.
> > /*
> > * For now, we report if PG_reserved was found set, but do not
> > * clear it, and do not free the page. But we shall soon need
> > * to do more, for when the ZERO_PAGE count wraps negative.
> > */
> > - return PageReserved(page);
> > + if (PageReserved(page))
> > + return 1;
> > + if (page->flags & PAGE_FLAGS_CHECK_AT_PREP)
> > + page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
> > + return 0;
>
> The name PAGE_FLAGS_CHECK_AT_PREP is strange. We clear these flags without
> message.
Would you be happier with PAGE_FLAGS_CLEAR_AT_FREE, then?
That would be fine by me, even if we add the gap to mmzone later.
One of the problems with PREP is that it's not obvious that it
means ALLOC: yes, I'd be happier with PAGE_FLAGS_CLEAR_AT_FREE.
> This is equal to
>
> page->flags &=~PAGE_FLAGS_CHECK_AT_PREP;
>
> You can drop the if...
I was intentionally following the existing style of
if (PageDirty(page))
__ClearPageDirty(page);
if (PageSwapBacked(page))
__ClearPageSwapBacked(page);
which is going out of its way to avoid dirtying a cacheline.
In all the obvious cases, I think the cacheline will already
be dirty; but I guess there's an important case (high order
but not compound?) which has a lot of clean cachelines.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists