From: "ying.huang@intel.com" <ying.huang@intel.com>
To: Jagdish Gediya <jvgediya@linux.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@suse.com>, Rik van Riel <riel@surriel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Yang Shi <shy828301@gmail.com>, Zi Yan <ziy@nvidia.com>,
Wei Xu <weixugc@google.com>, osalvador <osalvador@suse.de>,
Shakeel Butt <shakeelb@google.com>,
Zhong Jiang <zhongjiang-ali@linux.alibaba.com>
Subject: Re: [PATCH 1/3] memory tiering: hot page selection with hint page fault latency
Date: Fri, 15 Apr 2022 10:42:31 +0800 [thread overview]
Message-ID: <bf23f05830db51bab3b06bac6e54d4743d37e955.camel@intel.com> (raw)
In-Reply-To: <YlggP5Tub19gjF4g@li-6e1fa1cc-351b-11b2-a85c-b897023bb5f3.ibm.com>
Hi, Jagdish,
On Thu, 2022-04-14 at 18:53 +0530, Jagdish Gediya wrote:
> On Fri, Apr 08, 2022 at 03:12:20PM +0800, Huang Ying wrote:
[snip]
> > +
> > +static int numa_hint_fault_latency(struct page *page)
> > +{
> > + int last_time, time;
> > +
> > + time = jiffies_to_msecs(jiffies);
> > + last_time = xchg_page_access_time(page, time);
> > +
> > + return (time - last_time) & PAGE_ACCESS_TIME_MASK;
>
> This code can possibly consider cold page as hot,
>
> Assume,
>
> LAST_CPUPID_SHIFT = 12
> PAGE_ACCESS_TIME_BUCKETS = 0
> sysctl_numa_balancing_hot_threshold = 1000
>
> Assume while changing pte,
> jiffies_to_msecs(jiffies) = 0xAABB0100
>
> So value saved in page->flags will be lowest 12 bits of 0xAABB0100
> which is 0x100.
>
> Assume when numa_hint_fault_latency() gets called,
> time = jiffies_to_msecs(jiffies) = 0xAACC0100
>
> So, time = 0xAACC0100, and last_time = 0x100,
> time - last_time = 0xAACC0100 - 0x100 = 0xAACC0000
> 0xAACC0000 & PAGE_ACCESS_TIME_MASK = 0xAACC0000 & ((1 << 12) - 1) = 0
>
> so the return value of this function is 0, the code will consider it as
> hot page but it is cold page because actual difference is
> 0xAACC0100 - 0xAABB0100 = 110000 ms
>
Yes. This is possible.
> There may be more such scenarios. What do you think?
The algorithm just works statistically correct. That is, for really hot
pages, their hint page fault latency will be short and we can promote it
when they are accessed. For cold pages, it's still possible for them to
be identified as hot pages. But the possibility is much lower than that
of the hot pages.
We can try to improve further here. But as the first step, I want to
keep the algorithm as simple as possible. Then we can try improve it
step by step and show benefit in each step to justify the further
optimization.
> > +}
> > +
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2022-04-15 2:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-08 7:12 [PATCH 0/3] memory tiering: hot page selection Huang Ying
2022-04-08 7:12 ` [PATCH 1/3] memory tiering: hot page selection with hint page fault latency Huang Ying
2022-04-14 13:23 ` Jagdish Gediya
2022-04-15 2:42 ` ying.huang [this message]
2022-04-08 7:12 ` [PATCH 2/3] memory tiering: rate limit NUMA migration throughput Huang Ying
2022-04-08 7:12 ` [PATCH 3/3] memory tiering: adjust hot threshold automatically Huang Ying
2022-04-09 4:07 ` [PATCH 0/3] memory tiering: hot page selection Andrew Morton
2022-04-11 8:16 ` ying.huang
2022-04-09 4:00 [PATCH 1/3] memory tiering: hot page selection with hint page fault latency kernel test robot
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=bf23f05830db51bab3b06bac6e54d4743d37e955.camel@intel.com \
--to=ying.huang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=jvgediya@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=shakeelb@google.com \
--cc=shy828301@gmail.com \
--cc=weixugc@google.com \
--cc=zhongjiang-ali@linux.alibaba.com \
--cc=ziy@nvidia.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.