This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH V3 2/2] mm: Extend memory hotplug API to allow me

To: Daniel Kiper <dkiper@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH V3 2/2] mm: Extend memory hotplug API to allow memory hotplug in virtual machines
From: David Rientjes <rientjes@xxxxxxxxxx>
Date: Wed, 18 May 2011 20:36:02 -0700 (PDT)
Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, ian.campbell@xxxxxxxxxx, haicheng.li@xxxxxxxxxxxxxxx, konrad.wilk@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, dan.magenheimer@xxxxxxxxxx, v.tolstov@xxxxxxxxx, dave@xxxxxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, andi.kleen@xxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, fengguang.wu@xxxxxxxxx, wdauchy@xxxxxxxxx
Delivery-date: Wed, 18 May 2011 20:37:04 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305776176; bh=nvqewRdC32oi1w7flx8Kx17novg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=IzIBKHwKcY6mc06XR84OBRShIYFRmlCwwASOw/mpvqNJ24QcQBSVp/kA3m+liCiYR Xu4I/6Gupx0QhR4uc/jUw==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:date:from:x-x-sender:to:cc:subject:in-reply-to :message-id:references:user-agent:mime-version:content-type; bh=tlKhjihc4vapknmj4/ILCgxypuqY7IhNcc13gGSUsss=; b=VfWbmvpfrfq1SwEUCjpPSWdApmpbwPY28fxOtthJrV2E+k6gJT8BrHhIq/j+UqxpSv Yp/IuBr3KHIK7cIe44/A==
Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=DB5XkknWPpNG3XJEktzrznqrWZktjh3GfAxyKttCK1oNSEapzED3HnrAtrybB9tKRu BQsCFiwDUB4CJGwu4TwA==
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110517213858.GC30232@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110517213858.GC30232@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Tue, 17 May 2011, Daniel Kiper wrote:

> This patch contains online_page_callback and apropriate functions for
> setting/restoring online page callbacks. 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_set_limits(),
> __online_page_increment_counters() and __online_page_free() function
> was added to ease generic hotplug operation.

There are several issues with this.

First, this is completely racy and only allows one global callback to be 
in use at a time without looping, which is probably why you had to pass an 
argument to restore_online_page_callback().  Your implementation also 
requires that a callback must be synchronized with itself for the 
comparison to generic_online_page to make any sense.  Nobody knows which 
callback is effective at any given moment and has no guarantees that when 
they've set the callback that it will be the one called, otherwise.

Second, there's no explanation offered about why you have to split 
online_page() into three separate functions.  In addition, you've exported 
all of them so presumably modules will need to be doing this when loading 
or unloading and that further complicates the race mentioned above.

Third, there are no followup patches that use this interface or show how 
you plan on using it (other than eluding that it will be used for virtual 
machines in the changelog) so we're left guessing as to why we need it 
implemented in this fashion and restricts the amount of help I can offer 
because I don't know the problem you're facing.

Xen-devel mailing list