Received-SPF: pass (google.com: domain of linux-kernel+bounces-127277-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: "Huang, Ying" <ying.huang@intel.com>
To: Bharata B Rao <bharata@amd.com>
Cc: <linux-mm@kvack.org>,  <linux-kernel@vger.kernel.org>,
  <akpm@linux-foundation.org>,  <mingo@redhat.com>,
  <peterz@infradead.org>,  <mgorman@techsingularity.net>,
  <raghavendra.kt@amd.com>,  <dave.hansen@linux.intel.com>,
  <hannes@cmpxchg.org>
Subject: Re: [RFC PATCH 0/2] Hot page promotion optimization for large
 address space
In-Reply-To: <7e373c71-b2dc-4ae4-9746-c840f2a513a5@amd.com> (Bharata B. Rao's
	message of "Mon, 1 Apr 2024 17:50:57 +0530")
References: <20240327160237.2355-1-bharata@amd.com>
	<87il16lxzl.fsf@yhuang6-desk2.ccr.corp.intel.com>
	<dd2bc563-7654-4d83-896e-49a7291dd1aa@amd.com>
	<87edbulwom.fsf@yhuang6-desk2.ccr.corp.intel.com>
	<929b22ca-bb51-4307-855f-9b4ae0a102e3@amd.com>
	<875xx5lu05.fsf@yhuang6-desk2.ccr.corp.intel.com>
	<7e373c71-b2dc-4ae4-9746-c840f2a513a5@amd.com>
Date: Tue, 02 Apr 2024 10:03:34 +0800
Message-ID: <87o7asfrm1.fsf@yhuang6-desk2.ccr.corp.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii

Bharata B Rao <bharata@amd.com> writes:

> On 29-Mar-24 6:44 AM, Huang, Ying wrote:
>> Bharata B Rao <bharata@amd.com> writes:
> <snip>
>>> I don't think the pages are cold but rather the existing mechanism fails
>>> to categorize them as hot. This is because the pages were scanned way
>>> before the accesses start happening. When repeated accesses are made to
>>> a chunk of memory that has been scanned a while back, none of those
>>> accesses get classified as hot because the scan time is way behind
>>> the current access time. That's the reason we are seeing the value
>>> of latency ranging from 20s to 630s as shown above.
>> 
>> If repeated accesses continue, the page will be identified as hot when
>> it is scanned next time even if we don't expand the threshold range.  If
>> the repeated accesses only last very short time, it makes little sense
>> to identify the pages as hot.  Right?
>
> The total allocated memory here is 192G and the chunk size is 1G. Each
> time one such 1G chunk is taken up randomly for generating memory accesses.
> Within that 1G, 262144 random accesses are performed and 262144 such
> accesses are repeated for 512 times. I thought that should be enough
> to classify that chunk of memory as hot.

IIUC, some pages are accessed in very short time (maybe within 1ms).
This isn't repeated access in a long period.  I think that pages
accessed repeatedly in a long period are good candidates for promoting.
But pages accessed frequently in only very short time aren't.

> But as we see, often times
> the scan time is lagging the access time by a large value.
>
> Let me instrument the code further to learn more insights (if possible)
> about the scanning/fault time behaviors here.
>
> Leaving the fault count based threshold apart, do you think there is
> value in updating the scan time for skipped pages/PTEs during every
> scan so that the scan time remains current for all the pages?

No, I don't think so.  That makes hint page fault latency more
inaccurate.

>> 
>> The bits to record scan time or hint page fault is limited, so it's
>> possible for it to overflow anyway.  We scan scale time stamp if
>> necessary (for example, from 1ms to 10ms).  But it's hard to scale fault
>> counter.  And nobody can guarantee the frequency of hint page fault must
>> be less 1/ms, if it's 10/ms, it can record even short interval.
>
> Yes, with the approach I have taken, the time factor is out of the
> equation and the notion of hotness is purely a factor of the number of
> faults (or accesses)

Sorry, I don't get your idea here.  I think that the fault count may be
worse than time in quite some cases.

--
Best Regards,
Huang, Ying