linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yasunori Goto <ygoto@us.fujitsu.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
	Linux Hotplug Memory Support <lhms-devel@lists.sourceforge.net>,
	Linux-Node-Hotplug <lhns-devel@lists.sourceforge.net>,
	linux-mm <linux-mm@kvack.org>,
	"BRADLEY CHRISTIANSEN [imap]" <bradc1@us.ibm.com>
Subject: Re: [Lhms-devel] Re: [Lhns-devel] Merging Nonlinear and Numa style memory hotplug
Date: Thu, 24 Jun 2004 15:19:30 -0700	[thread overview]
Message-ID: <20040624135838.F009.YGOTO@us.fujitsu.com> (raw)
In-Reply-To: <1088083724.3918.390.camel@nighthawk>

Dave-san.

Probably, all of your advices are right.
I was confused between my emulation environment and true NUMA machine.
I will modify them. Thanks a lot.

BTW, I have a question about nonlinear patch.
It is about difference between phys_section[] and mem_section[]
I suppose that phys_section[] looks like no-meaning now.
If it isn't necessary, __va() and __pa() translation can be more simple.
What is the purpose of phys_section[]. Is it for ppc64?

Bye.

> Some more comments on the first patch:
> 
> +#ifdef CONFIG_HOTPLUG_MEMORY_OF_NODE
> +               if (node_online(nid)) {
> +                       allocate_pgdat(nid);
> +                       printk ("node %d will remap to vaddr %08lx\n", nid,
> +                               (ulong) node_remap_start_vaddr[nid]);
> +               }else
> +                       NODE_DATA(nid)=NULL;
> +#else
>                 allocate_pgdat(nid);
>                 printk ("node %d will remap to vaddr %08lx - %08lx\n", nid,
>                         (ulong) node_remap_start_vaddr[nid],
>                         (ulong) pfn_to_kaddr(highstart_pfn
>                             - node_remap_offset[nid] + node_remap_size[nid]));
> +#endif
> 
> I don't think this chunk is very necessary.  The 'NODE_DATA(nid)=NULL;'
> is superfluous because the node_data[] is zeroed at boot:
> 
> NUMA:
> #define NODE_DATA(nid) (node_data[nid])
> non-NUMA:
> #define NODE_DATA(nid) (&contig_page_data)
> 
> Why not just make it:
> 
> +               if (!node_online(nid))
> +			continue;
> 
> That should at least get rid of the ifdef.
> 
> -       bootmap_size = init_bootmem_node(NODE_DATA(0), min_low_pfn, 0, system_max_low_pfn);
> +       bootmap_size = init_bootmem_node(NODE_DATA(0), min_low_pfn, 0,
> +           (system_max_low_pfn > node_end_pfn[0]) ?
> +           node_end_pfn[0] : system_max_low_pfn);
> 
> -       register_bootmem_low_pages(system_max_low_pfn);
> +       register_bootmem_low_pages((system_max_low_pfn > node_end_pfn[0]) ?
> +           node_end_pfn[0] : system_max_low_pfn);
> 
> How about using a temp variable here instead of those nasty conditionals?
> 
> +
> +#ifdef CONFIG_HOTPLUG_MEMORY_OF_NODE
> +               if (node_online(nid)){
> +                       if (nid)
> +                               memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
> +                       NODE_DATA(nid)->pgdat_next = pgdat_list;
> +                       pgdat_list = NODE_DATA(nid);
> +                       NODE_DATA(nid)->enabled = 1;
> +               }
> +#else
>                 if (nid)
>                         memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
>                 NODE_DATA(nid)->pgdat_next = pgdat_list;
>                 pgdat_list = NODE_DATA(nid);
> +#endif
> 
> I'd just take the ifdef out.  Wouldn't this work instead?
> 
> -               if (nid)
> -                       memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
> -               NODE_DATA(nid)->pgdat_next = pgdat_list;
> -               pgdat_list = NODE_DATA(nid);
> +               if (node_online(nid)){
> +                       if (nid)
> +                               memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
> +                       NODE_DATA(nid)->pgdat_next = pgdat_list;
> +                       pgdat_list = NODE_DATA(nid);
> +                       NODE_DATA(nid)->enabled = 1;
> +               }
> 
> +void set_max_mapnr_init(void)
> +{
> ...
> +       struct page *hsp=0;
> 
> Should just be 'struct page *hsp = NULL;'
> 
> +       for(i = 0; i < numnodes; i++) {
> +               if (!NODE_DATA(i))
> +                       continue;
> +               pgdat = NODE_DATA(i);
> +               size = pgdat->node_zones[ZONE_HIGHMEM].present_pages;
> +               if (!size)
> +                       continue;
> +               hsp = pgdat->node_zones[ZONE_HIGHMEM].zone_mem_map;
> +               if (hsp)
> +                       break;
> +       }
> 
> Doesn't this just find the lowest-numbered node's highmem?  Are you sure
> that no NUMA systems have memory at lower physical addresses on
> higher-numbered nodes?  I'm not sure that this is true.
> 
> +       if (hsp)
> +               highmem_start_page = hsp;
> +       else
> +               highmem_start_page = (struct page *)-1;
> 
> By not just BUG() here?  Do you check for 'highmem_start_page == -1' somewhere?
> 
> @@ -478,12 +482,35 @@ void __init mem_init(void)
>         totalram_pages += __free_all_bootmem();
> 
>         reservedpages = 0;
> +
> +#ifdef CONFIG_HOTPLUG_MEMORY_OF_NODE
> +       for (nid = 0; nid < numnodes; nid++){
> +               int start, end;
> +
> +               if ( !node_online(nid))
> +                       continue;
> +               if ( node_start_pfn[nid] >= max_low_pfn )
> +                       break;
> +
> +               start = node_start_pfn[nid];
> +               end = ( node_end_pfn[nid] < max_low_pfn) ?
> +                       node_end_pfn[nid] : max_low_pfn;
> +
> +               for ( tmp = start; tmp < end; tmp++)
> +                       /*
> +                        * Only count reserved RAM pages
> +                        */
> +                       if (page_is_ram(tmp) && PageReserved(pfn_to_page(tmp)))
> +                               reservedpages++;
> +       }
> +#else
> 
> Again, I don't see what this loop is used for.  You appear to be trying
> to detect which nodes have lowmem.  Is there currently any x86 NUMA
> architecture that has lowmem on any node but node 0?
> 
> 
> 
> -- Dave
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Lhns-devel mailing list
> Lhns-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lhns-devel

-- 
Yasunori Goto <ygoto at us.fujitsu.com>


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-06-24 22:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-22 19:00 Yasunori Goto
2004-06-23 22:32 ` [Lhns-devel] " Dave Hansen
2004-06-24  3:04   ` Yasunori Goto
2004-06-24  3:26     ` Dave Hansen
2004-06-24 13:28     ` [Lhms-devel] " Dave Hansen
2004-06-24 22:19       ` Yasunori Goto [this message]
2004-06-24 22:37         ` Dave Hansen
2004-06-25  3:11           ` [Lhms-devel] " Yasunori Goto
2004-06-25  3:19             ` Dave Hansen
2004-06-25 18:48               ` Yasunori Goto
2004-06-25 18:59                 ` Dave Hansen
2004-06-25 20:45                   ` Yasunori Goto
2004-06-25 20:49                     ` Dave Hansen
2004-06-25 20:54                     ` Dave Hansen
2004-06-25  4:49         ` [Lhms-devel] Re: [Lhns-devel] " Shai Fultheim
2004-06-25 15:16           ` Dave Hansen

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=20040624135838.F009.YGOTO@us.fujitsu.com \
    --to=ygoto@us.fujitsu.com \
    --cc=bradc1@us.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=lhns-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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