Re: [Xen-devel] [PATCH v3 5/9] mm: Do not discard already-scrubbed pages if softirqs are pending

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.05.17 at 15:51, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 05/05/2017 06:27 AM, Jan Beulich wrote:
>>>>> On 04.05.17 at 19:18, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 05/04/2017 11:43 AM, Jan Beulich wrote:
>>>>>>> On 14.04.17 at 17:37, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>> While scrubbing from idle loop, check for softirqs every 256 pages.
>>>>> If softirq is pending, don't scrub any further and merge the
>>>>> partially-scrubbed buddy back into heap by breaking the clean portion
>>>>> into smaller power-of-2 chunks. Then repeat the same process for the
>>>>> dirty part.
>>>> This is ugly, as it gets us back into the state where full merge
>>>> opportunities aren't being realized, just that the time window
>>>> may be smaller now. As hinted at before, is there no way to
>>>> flag the first page needing scrubbing alongside the head
>>>> indicating that _some_ page needs scrubbing? The pages are
>>>> all free, so if there's no other suitable storage, the head page
>>>> itself could serve as such. But instead of a flag in struct
>>>> page_info, perhaps you could store a (relatively small) integer?
>>> How will it help? Even if we know what the fist dirty page is we still
>>> may have to drop scrubbing if irq is pending. We simply will not have to
>>> scan the buddy until first dirty page is found.
>>>
>>> Or perhaps I don't understand what you are suggesting.
>> If you get a request to stop scrubbing, you split the current
>> buddy into a clean and a (possibly) dirty part (if I understood
>> the code in this patch correctly). 
> 
> Right.
> 
>> It's that splitting which I'd like
>> to see avoided, and by keeping a "first dirty" index (which
>> would be updated when you stop scrubbing) you could do so.
> 
> 
> If we are to avoid splitting then we might just keep the buddy on the
> "dirty end" (i.e tail) of the order if we are interrupted in the middle.
> 
> Having "first_dirty" (which is really "maybe_first_dirty") would only
> help us start next scan faster but it won't really change the algorithm.
> 
> (Or maybe that's exactly what you are proposing.)

Yes - using such a hint means better chances of actually making
overall progress despite not splitting buddies.

Jan


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