[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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?

>> And of course if the override variable was per-CPU, you wouldn't
>> have a need to know, as you wouldn't try scrubbing on the CPU
>> doing the Dom0 setup.
> 
> Actually, won't (override != current) do the trick?

This is like saying "If I don't get a car, it should be a red one." If
you don't need to know, how can it matter what expression to use?

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.