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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Feb 22, 2019 at 05:47:13AM -0700, Jan Beulich wrote:
> >>> 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

Remove the code that returns those 17 pages.

> 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.
> 

Sure. But in my opinion there will only be one such wastage in the life
time of system then opting for simpler code is a far better approach
(with appropriate checks in place). On the other hand, if not returning
pages results in wasting almost half of each allocation, we will need to
think of a clever way. Your reply made me think of the former.

I have only realised this today: essentially we will end up implementing
xmalloc with vmalloc, which at the moment depends on xmalloc to allocate
the array of mfns.

Wei.

> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel