[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping
On Wed, Sep 09, 2015 at 08:33:52AM -0600, Jan Beulich wrote: > >>> On 09.09.15 at 16:20, <konrad.wilk@xxxxxxxxxx> wrote: > > Perhaps the solution is remove the first printk(s) and just have them > > once the operation has completed? That may fix the outstanding tasklet > > problem? > > Considering that this is a tool stack based retry, how would the > hypervisor know when the _whole_ operation is done? I was merely thinking of moving the printk _after_ the map_mmio_regions so there wouldn't be any outstanding preemption points in map_mmio_regions (so it can at least do the 64 PFNs). But going forward a couple of ideas: - The 64 limit was arbitrary. It could have been 42 or PFNs / num_online_cpus(), or actually finding out the size of the BAR and figuring the optimal case so that it will be done under 1ms. Or perhaps just provide an boot time parameter for those that really are struggling with this. - Perhaps add a new API to the P2M code so it can do the operations in batches. Our map_mmio_region iterates over every PFN which is surely not efficient. Some batching could help? Maybe? What other code could benefit from this? Would the boot-time creation of IOMMU page-tables also help with this (which takes 10 minutes on a 1TB box BTW) - This printk can be altogether removed in the hypervisor and moved in the toolstack. That is the libxl xc_domain_add_to_physmap could itself use the logging facility (xc_report?) the action. > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |