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]
Date:	Tue, 29 Mar 2011 20:32:42 +0200
From:	Daniel Kiper <dkiper@...-space.pl>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Daniel Kiper <dkiper@...-space.pl>, ian.campbell@...rix.com,
	akpm@...ux-foundation.org, andi.kleen@...el.com,
	haicheng.li@...ux.intel.com, fengguang.wu@...el.com,
	jeremy@...p.org, konrad.wilk@...cle.com,
	dan.magenheimer@...cle.com, v.tolstov@...fip.ru, pasik@....fi,
	wdauchy@...il.com, rientjes@...gle.com,
	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 3/3] mm: Extend memory hotplug API to allow memory hotplug in virtual machines

On Mon, Mar 28, 2011 at 09:25:24AM -0700, Dave Hansen wrote:
> On Mon, 2011-03-28 at 11:25 +0200, Daniel Kiper wrote:
> > This patch contains online_page_chain and apropriate functions
> > for registering/unregistering online page notifiers. It allows
> > to do some machine specific tasks during online page stage which
> > is required to implement memory hotplug in virtual machines.
> > Additionally, __online_page_increment_counters() and
> > __online_page_free() function was add to ease generic
> > hotplug operation.
>
> I really like that you added some symbolic constants there.  It makes it
> potentially a lot more readable.
>
> My worry is that the next person who comes along is going to _really_
> scratch their head asking why they would use:
> OP_DO_NOT_INCREMENT_TOTAL_COUNTERS or: OP_INCREMENT_TOTAL_COUNTERS.
> There aren't any code comments about it, and the patch description
> doesn't really help.
>
> In the end, we're only talking about a couple of lines of code for each
> case (reordering the function a bit too):
>
>         void online_page(struct page *page)
>         {
>         // 1. pfn-based bits upping the max physical address markers:
>                 unsigned long pfn = page_to_pfn(page);
>                 if (pfn >= num_physpages)
>                         num_physpages = pfn + 1;
>         #ifdef CONFIG_FLATMEM
>                 max_mapnr = max(page_to_pfn(page), max_mapnr);
>         #endif
>
>         // 2. number of pages counters:
>                 totalram_pages++;
>         #ifdef CONFIG_HIGHMEM
>                 if (PageHighMem(page))
>                         totalhigh_pages++;
>         #endif
>
>         // 3. preparing 'struct page' and freeing:
>                 ClearPageReserved(page);
>                 init_page_count(page);
>                 __free_page(page);
>         }
>
> Your stuff already extracted the free stuff very nicely.  I think now we
> just need to separate out the totalram_pages/totalhigh_pages bits from
> the num_physpages/max_mapnr ones.

What do you think about __online_page_increment_counters()
(totalram_pages and totalhigh_pages) and
__online_page_set_limits() (num_physpages and max_mapnr) ???

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ