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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 05/05/2017 12:05 PM, Jan Beulich wrote:
>>>> On 05.05.17 at 17:23, <boris.ostrovsky@oracle.com> wrote:
>> On 05/05/2017 10:51 AM, Jan Beulich wrote:
>>>>>> On 05.05.17 at 16:27, <boris.ostrovsky@oracle.com> wrote:
>>>> On 05/05/2017 10:14 AM, Jan Beulich wrote:
>>>>>>>> On 05.05.17 at 16:10, <JBeulich@suse.com> wrote:
>>>>>>>>> On 05.05.17 at 15:42, <boris.ostrovsky@oracle.com> 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)?

Either global or per-cpu override will need to be checked by the
scrubber when it is called from the idle loop. Or I don't understand
what you mean by "kicking off".

-boris

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