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

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



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

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