All of lore.kernel.org
 help / color / mirror / Atom feed
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH] do not count pages in holes with sparsemem
Date: Tue, 11 Jul 2006 10:33:31 +0200	[thread overview]
Message-ID: <44B3625B.7000700@innova-card.com> (raw)
In-Reply-To: <20060710.233454.39153668.anemo@mba.ocn.ne.jp>

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

  reply	other threads:[~2006-07-11  8:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-05 13:13 [PATCH] do not count pages in holes with sparsemem Atsushi Nemoto
2006-07-05 13:58 ` Franck Bui-Huu
2006-07-05 14:17   ` Atsushi Nemoto
2006-07-06 13:12     ` Franck Bui-Huu
2006-07-06 14:36       ` Atsushi Nemoto
2006-07-06 14:59         ` Franck Bui-Huu
2006-07-06 15:05           ` Franck Bui-Huu
2006-07-06 15:26             ` Atsushi Nemoto
2006-07-08 14:39               ` Franck Bui-Huu
2006-07-08 16:03                 ` Atsushi Nemoto
2006-07-08 16:15                   ` Franck Bui-Huu
2006-07-09 12:56                     ` Atsushi Nemoto
2006-07-10 11:34               ` Franck Bui-Huu
2006-07-10 14:34                 ` Atsushi Nemoto
2006-07-11  8:33                   ` Franck Bui-Huu [this message]
2006-07-11 13:24                     ` Atsushi Nemoto
2006-07-26 14:33                       ` Franck Bui-Huu
2006-07-26 15:21                         ` Atsushi Nemoto
2006-07-27  9:00                           ` Franck Bui-Huu
2006-07-28 12:48                             ` Atsushi Nemoto
2006-09-24  9:48 ` girish

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=44B3625B.7000700@innova-card.com \
    --to=vagabon.xyz@gmail.com \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.