Re: [PATCH 1 of 8] x86/mm: Fix paging_load

[Olaf Hering <olaf@aepfle.de>]

On Thu, Jan 26, Andres Lagar-Cavilla wrote:

> Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
> provide feedback as to whether
> 1. remove p2m_ram_paging_in
> 2. rename p2m_ram_paging_in_start to p2m_ram_paging_in
> 
> sounds like a good plan?

In my opinion the common case is that evicted pages get populated, an
request is sent. Later an response is expected to make room in the ring.

If p2m_mem_paging_populate allocates a page for the guest, it can let
the pager know that it did so (or failed to allocate one).
If there is a page already, the pager can copy the gfn content into a
buffer, put a pointer to it in the response and let
p2m_mem_paging_resume() handle both the ring accounting (as it does now)
and also the copy_from_user.
If page allocation failed, the pager has to allocate one via
p2m_mem_paging_prep() as it is done now, as an intermediate step.

The buffer page handling in the pager is probably simple, it needs to
maintain RING_SIZE() buffers. There cant be more than that in flight
because thats the limit of requests as well. In other words, the pager
does not need to wait for p2m_mem_paging_resume() to run and pull the
buffer content.


If the "populate - allocate - put_request - get_request - fill_buffer -
put_response - resume  get_response - copy_from_buffer - resume_vcpu"
cycle works, it would reduce the overall amount of work to be done
during paging, even if the hypercalls itself are not the bottleneck.
It all depends on the possibility to allocate a page in the various
contexts where p2m_mem_paging_populate is called.

The resume part could be done via eventchannel and
XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME could be removed.

Also the question is if freeing one p2mt is more important than reducing
the number if hypercalls to execute at runtime.

Olaf