linux-mips
[Top] [All Lists]

Re: [PATCH] do not count pages in holes with sparsemem

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: [PATCH] do not count pages in holes with sparsemem
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
Date: Tue, 11 Jul 2006 10:33:31 +0200
Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org, ralf@linux-mips.org
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=oWante4wEqW7XS6sFVOCCWpcwEDO6peQLed5/y20uk9+qZ2u9KEvSQgZlU7IrX2KNez10uwmE2+fSpWff4DTb+eoBotyDmAowAQuXNC0jOk5ixAL64gH+VgF/a+cM7N7yIdKnO6PjHyUBX2dCh1FjG84Vrzo0G2N4SIKDP26kc0=
In-reply-to: <20060710.233454.39153668.anemo@mba.ocn.ne.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <cda58cb80607060805yc656114p53516b904188c20f@mail.gmail.com> <20060707.002602.75184460.anemo@mba.ocn.ne.jp> <cda58cb80607100434h13831eb7rc6eda13a0d9e373f@mail.gmail.com> <20060710.233454.39153668.anemo@mba.ocn.ne.jp>
Reply-to: Franck <vagabon.xyz@gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 1.5.0.4 (X11/20060614)
Atsushi Nemoto wrote:
> On Mon, 10 Jul 2006 13:34:06 +0200, "Franck Bui-Huu" <vagabon.xyz@gmail.com> 
> wrote:
> 
>> can we use pfn_valid() instead of page_is_ram() ? bootmem_init() and
>> sparse_init() have already been called so pfn_valid() should be safe
>> here....
> 
> We can, but we can get more precise value using page_is_ram().  The
> pfn_valid() returns true for _all_ pages on present section, and
> currently the section size is 256MB.

so your total pages of RAM in show_mem() is incorrect...

               if (!pfn_valid(pfn))
                        continue;
                page = pfn_to_page(pfn);
                total++;


I don't know SPARSEMEM a lot but is it allowed to have holes inside
a section ? Shouldn't we tune the section size to avoid holes inside
section ?

> 
>>> -       max_mapnr = num_physpages = highend_pfn;
>>> +       max_mapnr = highend_pfn;
>>>  #else
>>> -       max_mapnr = num_physpages = max_low_pfn;
>>> +       max_mapnr = max_low_pfn;
>> this is not always true, specially if FLATMEM set and your physical mem
>> do not start at 0.
> 
> Yes, and I think you are preparing a patch for these systems ;-)
> 

good point :)

                Franck

<Prev in Thread] Current Thread [Next in Thread>