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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.05.17 at 18:49, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 05/05/2017 12:05 PM, Jan Beulich wrote:
>>>>> 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)?
> 
> 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".

I think some confusion arises from there being two different
proposals (of which I'd prefer the first):

The first is to make the override per-cpu. No kicking off is needed
in the case afaict, scrubbing can start right away if desired (albeit,
as was said, it may not make much sense prior to Dom0 having had
the bulk of its memory allocated, at least if its share isn't negligible
compared to the overall amount of memory).

The second is to leave the override as is, instead adding a call to
tell the scrubber to start doing its work. No need for any override
check in this case, as the override won't be used anymore from
the time of the mapcache_override_current(NULL) call (it is for
this reason that the kickoff call is to happen after this one).

Jan


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