Re: [Xen-devel] Converting heap page_infos to contiguous virtual

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/07/16 22:43, Boris Ostrovsky wrote:
> On 07/13/2016 05:06 PM, Andrew Cooper wrote:
>> On 13/07/2016 21:57, Boris Ostrovsky wrote:
>>> On 07/13/2016 04:34 PM, Andrew Cooper wrote:
>>>> On 13/07/2016 21:17, Boris Ostrovsky wrote:
>>>>> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>>>>>> On 13/07/16 20:44, Boris Ostrovsky wrote:
>>>>>>> I would like to clear a bunch of Xen heap pages at once (i.e. not
>>>>>>> page-by-page).
>>>>>>>
>>>>>>> Greatly simplifying things, let's say I grab (in common/page_alloc.c)
>>>>>>>     pg = page_list_remove_head(&heap(node, zone, order)
>>>>>>>
>>>>>>> and then
>>>>>>>
>>>>>>>     mfn_t mfn =
>>>>>>> _mfn(page_to_mfn(pg));                                        
>>>>>>>     char *va = mfn_to_virt(mfn_x(mfn));
>>>>>>>     memset(va, 0, 4096 * (1 << order));
>>>>>>>
>>>>>>>
>>>>>>> Would it be valid to this?
>>>>>> In principle, yes.  The frame_table is in order.
>>>>>>
>>>>>> However, mfn_to_virt() will blow up for RAM above the 5TB boundary.  You
>>>>>> need to map_domain_page() to get a mapping.
>>>>> Right, but that would mean going page-by-page, which I want to avoid.
>>>>>
>>>>> Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
>>>>> imply that it maps this big a range contiguously (modulo PDX hole)?
>>>> Your maths is correct, and yet you will end up with problems if you
>>>> trust it.
>>>>
>>>> That is the magic mode for the idle and monitor pagetables.  In the
>>>> context of a 64bit PV guest, the cutoff is at 5TB, at which point you
>>>> venture into the virtual address space reserved for guest kernel use. 
>>>> (It is rather depressing that the 64bit PV guest ABI is the factor
>>>> limiting Xen's maximum RAM usage.)
>>> I don't know whether it would make any difference but the pages that I am
>>> talking about are not in use by any guest, they are free. (This question
>>> is for scrubbing rewrite that I am working on. Which apparently you
>>> figured out judged by what you are saying below)
>> Being free is not relevant.  It depends whether current is a 64bit PV
>> guest or not.  Even in the idle loop, we don't context switch away from
>> current's pagetables.
>
> Can we force switch to idle (i.e. a non-64b PV guest) when we know
> it would be useful for mapping/scrubbing? The cost of TLB flush (if that
> was the reason) may be small compared to advantages brought by
> fast mapping during scrubbing.

It sounds like a plausible option, but would need some numbers to back
it up.

However, I would recommend getting something functioning first, before
trying to optimise it.

There is probably a lot to be gained simply by improving clear_page().

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel