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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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.)

-boris

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