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: > > On Wed, Aug 15, 2012 at 10:48:39AM +0100, Mel Gorman wrote: > > > On Wed, Aug 15, 2012 at 12:25:28PM +0300, Michael S. Tsirkin wrote: > > > > On Wed, Aug 15, 2012 at 10:05:28AM +0100, Mel Gorman wrote: > > > > > On Tue, Aug 14, 2012 at 05:11:13PM -0300, Rafael Aquini wrote: > > > > > > On Tue, Aug 14, 2012 at 10:51:39PM +0300, Michael S. Tsirkin wrote: > > > > > > > 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. > > 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
