[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature
On 08/11/2012 08:00, "Jan Beulich" <JBeulich@xxxxxxxx> wrote: >>>> On 07.11.12 at 23:17, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote: >> It appears that the attempt to use 2MB and 1GB pages is done in >> the toolstack, and if the hypervisor rejects it, toolstack tries >> smaller pages. Thus, if physical memory is highly fragmented >> (few or no order>=9 allocations available), this will result >> in one hypercall per 4k page so a 256GB domain would require >> 64 million hypercalls. And, since AFAICT, there is no sane >> way to hold the heap_lock across even two hypercalls, speeding >> up the in-hypervisor allocation path, by itself, will not solve >> the TOCTOU race. > > No, even in the absence of large pages, the tool stack will do 8M > allocations, just without requesting them to be contiguous. > Whether 8M is a suitable value is another aspect; that value may > predate hypercall preemption, and I don't immediately see why > the tool stack shouldn't be able to request larger chunks (up to > the whole amount at once). It is probably to allow other dom0 processing (including softirqs) to preempt the toolstack task, in the case that the kernel was not built with involuntary preemption enabled (having it disabled is the common case I believe?). 8M batches may provide enough returns to user space to allow other work to get a look-in. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |