linux-kernel - Re: [PATCH 3/3] mm: Extend memory hotplug API to allow memory hotplug in virtual machines

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:	Mon, 28 Mar 2011 09:25:24 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Daniel Kiper <dkiper@...-space.pl>
Cc:	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, 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.

If done right, this should also help the totalram_pages/totalhigh_pages
go away balloon_retrieve(), and make Xen less likely to break in the
future.  It also makes it immediately obvious why Xen skips incrementing
those counters: it does it later.

I also note that Xen has a copy of a part of online_page() in its
increase_reservation(): 

                /* Relinquish the page back to the allocator. */
                ClearPageReserved(page);
                init_page_count(page);
                __free_page(page);

That means that Xen is basically carrying an open-coded copy of
online_page() all by itself today.  

-- Dave

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