[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |