Thread (2 messages) 2 messages, 2 authors, 2012-08-21

Re: [PATCH v7 2/4] virtio_balloon: introduce migration primitives to balloon pages

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2012-08-15 11:28:04
Also in: linux-mm, lkml

On Wed, Aug 15, 2012 at 12:16:51PM +0100, Mel Gorman wrote:
On Wed, Aug 15, 2012 at 01:01:08PM +0300, Michael S. Tsirkin wrote:
quoted
On Wed, Aug 15, 2012 at 10:48:39AM +0100, Mel Gorman wrote:
quoted
On Wed, Aug 15, 2012 at 12:25:28PM +0300, Michael S. Tsirkin wrote:
quoted
On Wed, Aug 15, 2012 at 10:05:28AM +0100, Mel Gorman wrote:
quoted
On Tue, Aug 14, 2012 at 05:11:13PM -0300, Rafael Aquini wrote:
quoted
On Tue, Aug 14, 2012 at 10:51:39PM +0300, Michael S. Tsirkin wrote:
quoted
What I think you should do is use rcu for access.
And here sync rcu before freeing.
Maybe an overkill but at least a documented synchronization
primitive, and it is very light weight.
I liked your suggestion on barriers, as well.
I have not thought about this as deeply as I shouold but is simply rechecking
the mapping under the pages_lock to make sure the page is still a balloon
page an option? i.e. use pages_lock to stabilise page->mapping.
To clarify, are you concerned about cost of rcu_read_lock
for non balloon pages?
Not as such, but given the choice between introducing RCU locking and
rechecking page->mapping under a spinlock I would choose the latter as it
is more straight-forward.
OK but checking it how? page->mapping == balloon_mapping does not scale to
multiple balloons,
I was thinking of exactly that page->mapping == balloon_mapping check. As I
do not know how many active balloon drivers there might be I cannot guess
in advance how much of a scalability problem it will be.
Not at all sure multiple drivers are worth supporting, but multiple
*devices* is I think worth supporting, if for no other reason than that
they can work today. For that, we need a device pointer which Rafael
wants to put into the mapping, this means multiple balloon mappings.

quoted
so I hoped we can switch to
page->mapping->flags & BALLOON_MAPPING or some such,
but this means we dereference it outside the lock ...
That also sounded like future stuff to me that would be justified with
profiling if necessary. Personally I would have started with the spinlock
and a simple check and moved to RCU later when either scalability was a
problem or it was found there was a need to stabilise whether a page was
a balloon page or not outside a spinlock.

This is not a NAK to the idea and I'm not objecting to RCU being used now
if that is what is really desired. I just suspect it's making the series
more complex than it needs to be right now.

-- 
Mel Gorman
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help