Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.05.17 at 17:23, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 05/05/2017 10:51 AM, Jan Beulich wrote:
>>>>> On 05.05.17 at 16:27, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 05/05/2017 10:14 AM, Jan Beulich wrote:
>>>>>>> On 05.05.17 at 16:10, <JBeulich@xxxxxxxx> wrote:
>>>>>>>> On 05.05.17 at 15:42, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>>>>>> Otoh there's not much to scrub yet until Dom0 had all its memory
>>>>>>>>> allocated, and we know which pages truly remain free (wanting
>>>>>>>>> what is currently the boot time scrubbing done on them). But that
>>>>>>>>> point in time may still be earlier than when we switch to
>>>>>>>>> SYS_STATE_active.
>>>>>>> IOW I think boot scrubbing could be kicked off as soon as Dom0
>>>>>>> had the bulk of its memory allocated.
>>>>>> Since we only are trying to avoid mapcache vcpu override can't we just
>>>>>> scrub whenever override is NULL (per-cpu or not)?
>>>>> But how do you know? The variable should remain static in
>>>>> domain_page.c, so I think we'd instead need a notification to
>>>>> the scrubber when it gets set back to NULL.
>>> Why not just have in domain_page.c
>>>
>>> bool mapcache_override() {return override != NULL;}
>>>
>>> (or appropriate per-cpu variant)?
>> And you would mean to permanently poll this?
> 
> We have to permanently poll on/check something. Either it will be local
> to page_alloc.c or to domain_page.c.

Why can't this be kicked off right after zapping the override (if we
go that route in the first place; I think the per-cpu override would
be the more seamless approach)?

Jan


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