All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@amd.com>
To: "Huang, Ying" <ying.huang@intel.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 1/2] sched/numa: Fault count based NUMA hint fault latency
Date: Thu, 28 Mar 2024 10:09:50 +0530	[thread overview]
Message-ID: <e059df52-48fc-4e65-9eb0-c0d197625e6e@amd.com> (raw)
In-Reply-To: <87r0fvktkn.fsf@yhuang6-desk2.ccr.corp.intel.com>

On 28-Mar-24 7:26 AM, Huang, Ying wrote:
> Bharata B Rao <bharata@amd.com> writes:
> 
> [snip]
> 
>> @@ -1750,25 +1753,20 @@ static bool pgdat_free_space_enough(struct pglist_data *pgdat)
>>  }
>>  
>>  /*
>> - * For memory tiering mode, when page tables are scanned, the scan
>> - * time will be recorded in struct page in addition to make page
>> - * PROT_NONE for slow memory page.  So when the page is accessed, in
>> - * hint page fault handler, the hint page fault latency is calculated
>> - * via,
>> + * For memory tiering mode, when page tables are scanned, the current
>> + * hint fault count will be recorded in struct page in addition to
>> + * make page PROT_NONE for slow memory page.  So when the page is
>> + * accessed, in hint page fault handler, the hint page fault latency is
>> + * calculated via,
>>   *
>> - *	hint page fault latency = hint page fault time - scan time
>> + * hint page fault latency = current hint fault count - fault count at scan time
>>   *
>>   * The smaller the hint page fault latency, the higher the possibility
>>   * for the page to be hot.
>>   */
>> -static int numa_hint_fault_latency(struct folio *folio)
>> +static inline int numa_hint_fault_latency(struct folio *folio, int count)
>>  {
>> -	int last_time, time;
>> -
>> -	time = jiffies_to_msecs(jiffies);
>> -	last_time = folio_xchg_access_time(folio, time);
>> -
>> -	return (time - last_time) & PAGE_ACCESS_TIME_MASK;
>> +	return count - folio_xchg_fault_count(folio, count);
>>  }
> 
> I found count is task->mm->hint_faults.  That is a process wide
> counting.  How do you connect the hotness of a folio with the count of
> hint page fault in the process?  How do you compare the hotness of
> folios among different processes?

The global hint fault count that we already maintain could
be used instead of per-task fault. That should take care
of the concern you mention right?

Regards,
Bharata.

  reply	other threads:[~2024-03-28  4:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 16:02 [RFC PATCH 0/2] Hot page promotion optimization for large address space Bharata B Rao
2024-03-27 16:02 ` [RFC PATCH 1/2] sched/numa: Fault count based NUMA hint fault latency Bharata B Rao
2024-03-28  1:56   ` Huang, Ying
2024-03-28  4:39     ` Bharata B Rao [this message]
2024-03-28  5:21       ` Huang, Ying
2024-03-30  1:11   ` kernel test robot
2024-03-30  3:47   ` kernel test robot
2024-03-27 16:02 ` [RFC PATCH 2/2] mm: Update hint fault count for pages that are skipped during scanning Bharata B Rao
2024-03-28  5:35 ` [RFC PATCH 0/2] Hot page promotion optimization for large address space Huang, Ying
2024-03-28  5:49   ` Bharata B Rao
2024-03-28  6:03     ` Huang, Ying
2024-03-28  6:29       ` Bharata B Rao
2024-03-29  1:14         ` Huang, Ying
2024-04-01 12:20           ` Bharata B Rao
2024-04-02  2:03             ` Huang, Ying
2024-04-02  9:26               ` Bharata B Rao
2024-04-03  8:40                 ` Huang, Ying
2024-04-12  4:00                   ` Bharata B Rao
2024-04-12  7:28                     ` Huang, Ying
2024-04-12  8:16                       ` Bharata B Rao
2024-04-12  8:48                         ` Huang, Ying

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e059df52-48fc-4e65-9eb0-c0d197625e6e@amd.com \
    --to=bharata@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=raghavendra.kt@amd.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.