linux-kernel - Re: [Lhms-devel] [PATCH 1/10] hot-add-mem x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1154998617.5790.31.camel@keithlap>
Date:	Mon, 07 Aug 2006 17:56:56 -0700
From:	keith mannthey <kmannth@...ibm.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	andrew <akpm@...l.org>, discuss <discuss@...-64.org>,
	Andi Kleen <ak@...e.de>, lkml <linux-kernel@...r.kernel.org>,
	lhms-devel <lhms-devel@...ts.sourceforge.net>
Subject: Re: [Lhms-devel] [PATCH 1/10] hot-add-mem x86_64: acpi motherboard
	fix

On Tue, 2006-08-08 at 09:31 +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 07 Aug 2006 11:39:27 -0700
> keith mannthey <kmannth@...ibm.com> wrote:
> 
> > On Sat, 2006-08-05 at 14:51 +0900, KAMEZAWA Hiroyuki wrote:
> > > On Fri, 4 Aug 2006 07:13:51 -0600
> > > Keith Mannthey <kmannth@...ibm.com> wrote:
> > > > I have worked to integrate the feedback I recived on the last round of patches
> > > > and welcome more ideas/advice. Thanks to everyone who has provied input on
> > > > these patches already. 
> > > > 
> > > Just from review...
> > > 
> > > If new zone , which was empty at boot, are added into the system.
> > > build_all_zonelists() has to be called. (see online_pages() in memory_hotplug.c)
> > > it looks x86_64's __add_pages() doesn't calles it.
> > 
> > With RESERVE there are not empty zones.  All zones (including add-areas)
> > are setup during boot and hot add areas reserved in the bootmem
> > allocator. 
> > 
> > Zones don't change size there is no adding to the zone just on-lining on
> > pages at are already present in the zone. 
> >   
> Hmm, curious.
> please explain. 
> ==
> int __add_pages(struct zone *z, unsigned long start_pfn, unsigned long nr_pages)
> {
>         int err = -EIO;
>         unsigned long pfn;
>         unsigned long total = 0, mem = 0;
>         for (pfn = start_pfn; pfn < start_pfn + nr_pages; pfn++) {
>                 if (pfn_valid(pfn)) {
>                         online_page(pfn_to_page(pfn));
>                         err = 0;
>                         mem++;
>                 }
>                 total++;
>         }
>         if (!err) {
>                 z->spanned_pages += total;
>                 z->present_pages += mem; -------------------------------(*)

It is an accounting issue.  What I meant by re-sizing is there is no
change to node_mem_map (with reserve CONFIG_FLAT_NODE_MEM_MAP is set).
When the original size for the zone is setup it views that add areas as
a "hole" in the e820 space. 

See arch/x86_64/mm/init.c size_zones. 

> ==
> It looks contents of zone is increased at (*). Do I see old code ?
> 
> ==
> static inline int populated_zone(struct zone *zone)
> {
>         return (!!zone->present_pages);
> }
> ==
> "empty zone" I said means a zone which is not populated.

I know of no x86_64 hardware the supports empty node hot-add memory.  If
it exists I would recommend using SPARSEMEM based hot-add.  On HW I am
aware of there is always some memory present in a node at boot.   
 

Thanks,
  Keith 

-
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/