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, so I hoped we can switch to page->mapping->flags & BALLOON_MAPPING or some such, but this means we dereference it outside the lock ... We will also need to add some API to set/clear mapping so that driver does not need to poke in mm internals, but that's easy. > -- > Mel Gorman > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
