Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> On Fri, Dec 02, Andres Lagar-Cavilla wrote:
>
>> > The pager is in the process of writing the gfn to disk after
>> successful
>> > nomination. Its next step is the eviction, which will now fail because
>> > the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
>> > that failure.
>> > The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
>> > place.
>> Yes it was! The biggest source of overhead is I/O. Tell the pager to
>> stop
>> I/O early. Otherwise, you've done the paging out I/O pointlessly, to
>> find
>> out only when you try to finalize the eviction.
>
> I'm not sure how to inform the pager, its most likely in the middle of
> write(). Since such an event is rare (in my testing at least) I wonder
> wether its worth to make it complicated?

The way it is right now with the current ABI does better handling
vis-a-vis this problem (than short-cutting states and not sending an
EVICT_FAIL message).

A pager could nominate gfn's in batches, write them out in batches, evict
them in batches. It's a bit of a longshot, but exemplifies the kinds of
problems we need to think about when tinkering with the paging ABI.

On that topic. Is there a reason why a page cannot be proactively paged in
without attempting to map it first? I.e. move from p2m_ram_paging_out
straight into p2m_ram_paging_in with paging_prep/_load? It would eliminate
xenpaging's use of a page-in thread...

Andres

Andres
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel