[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.
> -----Original Message----- [snip] > >> >> I'm getting the impression that we're moving in circles. A blanket > >> >> limit above the 256 one for all domains is _not_ going to be > >> >> acceptable; going to 8k will still need host admin consent. With > >> >> your rangeset performance improvement patch, each range is > >> >> going to be tracked by a 40 byte structure (up from 32), which > >> >> already means an overhead increase for all the other ranges. 8k > >> >> of wp ranges implies an overhead beyond 448k (including the > >> >> xmalloc() overhead), which is not _that_ much, but also not > >> >> negligible. > >> >> > >> > > >> > ... which means we are still going to need a toolstack parameter to set > the > >> > limit. We already have a parameter for VRAM size so is having a > parameter > >> for > >> > max. GTT shadow ranges such a bad thing? > >> > >> It's workable, but not nice (see also Ian's earlier response). > >> > >> > Is the fact that the memory comes > >> > from xenheap rather than domheap the real problem? > >> > >> Not the primary one, since except on huge memory machines > >> both heaps are identical. To me the primary one is the quite > >> more significant resource consumption in the first place (I'm not > >> going to repeat what I've written in already way too many > >> replies before). > > > > Ok. Well the only way round tracking specific ranges for emulation (and > > consequently suffering the overhead) is tracking by type. For XenGT I > guess > > it would be possible to live with a situation where a single ioreq server > > can > > register all wp mem emulations for a given VM. I can't say I particularly > > like that way of doing things but if it's the only way forward then I guess > > we may have to live with it. > > Well, subject to Ian not objecting (still awaiting some follow-up by > him), I didn't mean to say doing it the proposed way is a no-go. > All that I really insist on is that this larger resource consumption > won't go without some form of host admin consent. > Would you be ok with purely host admin consent e.g. just setting the limit via boot command line? Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |