[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

  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 4 Jun 2021 15:23:09 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s6eHqYCXOWXBryVLpB90OwwJCuDcpY5PXTH/92MJ7XA=; b=E0ZWPYkzanD3N9bmOwQjeua5wouIrWskcp/iLbz/PIj9ghyrjrLJlkO17FqJYQN9x84XGfi8GuAYmDxJLcEFdJoDfp3mrq2VHk+4n+D9iHSfFb0q/gCG0DUxQlJrnDWmzAIMuMpPLPyjo0KhzWVXHLEYJq72OblV+VeXS6abgDaE8Bhle/MgFv+IX1xR70vMkRogNoYa+uhC1xk0D4Sf3KpSsIxSvZJpuBO+uN2HlWHF6NwYX3E7Lwr6XvipUpdlibzFvqFntsyKudGHdPcmNRRUV+9moyPcnRMK7NLzWHAkSgEoyIzBguEqF1PIODDP19zLA7J8HoMPhJOpDn6zzQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YLPgPDlzMj1AaUWWpWPv1lzbBMuAABhAtq2hkvkmmDpsicv5gDREegyFg+dveTvUQ+5N9RJRbmZTvJ0AtQlDIjs4+1CPqZTFGtOXvCXSHrbrsNBbAXTFsgv4z7tM+WcRg1e8kb967kHCt2I3SOVxaZreCd782b0J6L1ImkqfzFWMxGlIUAJxCA0T3UTGnVgcU2Yw2L+HXo3Vpy6edYCQuBTEDLhSS7rnReMoKPN7mcx2BBaXV6h7xJim8N3S9WFBklR1Q+9mXfaH/xduisbapLQeCy/LNtersPK2j1a9NFPnFe4ygGaHKLApMaobTtKUJPiAKOt1keMAuh7NnDqPAQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 04 Jun 2021 13:23:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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?




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