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

Re: [PATCH v2 07/12] mm: allow page scrubbing routine(s) to be arch controlled

Hi Jan,

On 04/06/2021 14:23, Jan Beulich wrote:
On 03.06.2021 11:39, Julien Grall wrote:
On 27/05/2021 14:58, Jan Beulich wrote:
On 27.05.2021 15:06, Julien Grall wrote:
On 27/05/2021 13:33, Jan Beulich wrote:
@@ -1046,12 +1051,14 @@ static struct page_info *alloc_heap_page
        if ( first_dirty != INVALID_DIRTY_IDX ||
             (scrub_debug && !(memflags & MEMF_no_scrub)) )
+        bool cold = d && d != current->domain;

So the assumption is if the domain is not running, then the content is
not in the cache. Is that correct?

Not exactly: For one, instead of "not running" it is "is not the current
domain", i.e. there may still be vCPU-s of the domain running elsewhere.
And for the cache the question isn't so much of "is in cache", but to
avoid needlessly bringing contents into the cache when the data is
unlikely to be used again soon.

Ok. Can this be clarified in the commit message?

I had updated it already the other day to

"Especially when dealing with large amounts of memory, memset() may not
  be very efficient; this can be bad enough that even for debug builds a
  custom function is warranted. We additionally want to distinguish "hot"
  and "cold" cases (with, as initial heuristic, "hot" being for any
  allocations a domain does for itself, assuming that in all other cases
  the page wouldn't be accessed [again] soon). The goal is for accesses
  of "cold" pages to not disturb caches (albeit finding a good balance
  between this and the higher latency looks to be difficult)."

Is this good enough?

Yes. Thank you for proposing an update to the commit message!


Julien Grall



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