[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080225192127.GA20322@shadowen.org>
Date: Mon, 25 Feb 2008 19:21:27 +0000
From: Andy Whitcroft <apw@...dowen.org>
To: Jörn Engel <joern@...fs.org>
Cc: Dave Hansen <haveblue@...ibm.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: Page scan keeps touching kernel text pages
On Mon, Feb 25, 2008 at 07:53:20PM +0100, Jörn Engel wrote:
> On Mon, 25 February 2008 09:48:22 -0800, Dave Hansen wrote:
> > On Mon, 2008-02-25 at 15:07 +0000, Andy Whitcroft wrote:
> > > shrink_page_list() would be expected to be passed pages pulled from
> > > the active or inactive lists via isolate_lru_pages()? I would not have
> > > expected to find the kernel text on the LRU and therefore not expect to
> > > see it passed to shrink_page_list()?
> >
> > It may have been kernel text at one time, but what about __init
> > functions? Don't we free that section back to the normal allocator
> > after init time? Those can end up on the LRU.
>
> Pages below 0x2ba should be non-init in my test kernel:
> c02ba000 T __init_begin
> ...
> c02d5000 B __init_end
>
> scanning zone DMA
> page 3fa 3 00000000 628
> page 2bf 2 00000000 628
> page 97 3 00000000 628
> page 98 2 00000000 628
>
> So __init explains one page of this minimal sample, but not the other
> three.
I thought that init sections were deliberatly pushed to the end of the
kernel when linked, cirtainly on my laptop here that seems to be so.
That would make the first two "after" the kernel. The other two appear
to be before the traditional kernel load address, which is 0x100000, so
those pages are before not in the kernel?
-apw
--
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