On Wed, Aug 15, 2012 at 01:01:08PM +0300, Michael S. Tsirkin wrote:

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.

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