[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

>>> On 22.02.19 at 13:11, <wei.liu2@xxxxxxxxxx> wrote:
> On Fri, Feb 22, 2019 at 05:06:03AM -0700, Jan Beulich wrote:
>> >>> On 22.02.19 at 12:50, <wei.liu2@xxxxxxxxxx> wrote:
>> > On Fri, Feb 22, 2019 at 04:48:09AM -0700, Jan Beulich wrote:
>> >> >>> On 20.02.19 at 18:08, <wei.liu2@xxxxxxxxxx> wrote:
>> >> > On Wed, Feb 20, 2019 at 01:09:56PM +0000, Wei Liu wrote:
>> >> > [...]
>> >> >> I think under-allocate-then-map looks plausible. xmalloc will need
>> >> >> to allocate pages, put them into an array and call __vmap on that array
>> >> >> directly.
>> >> > 
>> >> > The biggest issue with this approach is that we now need an array of
>> >> > 1UL<<MAX_ORDER to accommodate mfns. Back of envelope calculation: on x86
>> >> > this is going to be (1UL<<20)*8 bytes long. This is not feasible.
>> >> 
>> >> Are we really calling xmalloc() with any number nearly this big?
>> > 
>> > In practice, I don't think so. What do you think is a sensible limit?
>> I'm afraid you won't like the answer: Whatever the biggest chunk is
>> we currently allocate anywhere. Perhaps, e.g. if there's a single big
>> "violator", changing some code to reduce the upper bound might be
>> desirable.
>> In general there shouldn't be any going beyond one page once we've
>> completed booting. Several years back I think I had managed to
>> replace most (all?) higher order xmalloc()-s. So another option might
>> be to allow up to MAX_ORDER by way of some init-only mechanism,
>> and later allow only up to single page chunks.
> Think about it, if you have done the work to remove high order
> allocations, removing this optimisation is the easiest thing to do and
> wouldn't make things worse, isn't it?

Not sure I understand what exactly you want to remove. Allocating
32 pages when you need 17 is wasteful, and hence I'd prefer if we
could continue to make actual use of the remaining 15. That's
independent of whether the allocation occurs at boot or run time.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.