On 11/01/16 11:59, Vitaly Kuznetsov wrote: > David Vrabel <david.vrabel@xxxxxxxxxx> writes: > >> On 07/01/16 17:23, Vitaly Kuznetsov wrote: >>> >>> - Changes since 'v1': >>> Add 'online' parameter to add_memory_resource() as it is being used by >>> xen ballon driver and it adds "empty" memory pages [David Vrabel]. >>> (I don't completely understand what prevents manual onlining in this >>> case as we still have all newly added blocks in sysfs ... this is the >>> discussion point.) >> > > (there is a discussion with Daniel on the same topic in a parallel > thread) > >> I'm not sure what you're not understanding here? >> >> Memory added by the Xen balloon driver (whether populated with real >> memory or not) does need to be onlined by udev or similar. > > > Yes, same as all other memory hotplug mechanisms (hyper-v's balloon > driver and acpi memory hotplug). My patch adds an option to make this > happen automatically. Xen driver is currently excluded because of a > deadlock. If this deadlock is the only problem we can easily change > taking the lock to checking that the lock was taken (and taking in case > it wasn't) or something similar and everything is going to work. From > briefly looking at the code it seems to me it's going to work. I don't think Linux has recursive mutex that we could use for this. > What I wasn't sure about is 'empty pages' you were mentioning. In case > there are some pages we can't online there should be a protection > mechanism actively preventing them from going online (similar to > hv_online_page() in Hyper-V driver) as this patch does nothing > 'special' compared to udev onlining newly added blocks. 'Empty' (or unpopulated) pages are those without any physical RAM backing them. Backend drivers map foreign (from other guest) pages into these unpopulated pages. i.e., accesses by the kernel to the virtual addresses of these pages access memory shared by another guest. These empty pages are ones we would prefer to be always automatically onlined because they're hotplugged in response to requests from the backend drivers. Anyway, this series is fine with this Xen balloon driver limitation -- it can be addresses at a later date if necessary. David -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>