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