From: "Huang\, Ying" <ying.huang@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>, Rik van Riel <riel@redhat.com>,
Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Fengguang Wu <fengguang.wu@intel.com>
Subject: Re: [RFC 08/10] autonuma, memory tiering: Select hotter pages to promote to fast memory node
Date: Mon, 04 Nov 2019 10:41:10 +0800 [thread overview]
Message-ID: <87k18gcqih.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20191101092404.GS4131@hirez.programming.kicks-ass.net> (Peter Zijlstra's message of "Fri, 1 Nov 2019 10:24:04 +0100")
Hi, Peter,
Peter Zijlstra <peterz@infradead.org> writes:
> On Fri, Nov 01, 2019 at 03:57:25PM +0800, Huang, Ying wrote:
>> index 8ec38b11b361..59e2151734ab 100644
>> --- a/include/linux/mm_types.h
>> +++ b/include/linux/mm_types.h
>> @@ -484,6 +484,11 @@ struct mm_struct {
>>
>> /* numa_scan_seq prevents two threads setting pte_numa */
>> int numa_scan_seq;
>> +
>> +#define NUMA_SCAN_NR_HIST 16
>> + int numa_scan_idx;
>> + unsigned long numa_scan_jiffies[NUMA_SCAN_NR_HIST];
>> + unsigned long numa_scan_starts[NUMA_SCAN_NR_HIST];
>
> Why 16? This is 4 cachelines.
We want to keep the NUMA scanning history reasonably long. From
task_scan_min(), the minimal interval between task_numa_work() running
is about 100 ms by default. So we can keep 1600 ms history by default
if NUMA_SCAN_NR_HIST is 16. If user choose to use smaller
sysctl_numa_balancing_scan_size, then we can only keep shorter history.
In general, we want to keep no less than 1000 ms history. So 16 appears
like a reasonable choice for us. Any other suggestion?
>> #endif
>> /*
>> * An operation with batched TLB flushing is going on. Anything
>
>> +static long numa_hint_fault_latency(struct task_struct *p, unsigned long addr)
>> +{
>> + struct mm_struct *mm = p->mm;
>> + unsigned long now = jiffies;
>> + unsigned long start, end;
>> + int i, j;
>> + long latency = 0;
>> +
>> + i = READ_ONCE(mm->numa_scan_idx);
>> + i = i ? i - 1 : NUMA_SCAN_NR_HIST - 1;
>> + /*
>> + * Paired with smp_wmb() in task_numa_work() to check
>> + * scan range buffer after get current index
>> + */
>> + smp_rmb();
>
> That wants to be:
>
> i = smp_load_acquire(&mm->numa_scan_idx)
> i = (i - 1) % NUMA_SCAN_NR_HIST;
>
> (and because NUMA_SCAN_NR_HIST is a power of 2, the compiler will
> conveniently make that a bitwise and operation)
>
> And: "DEC %0; AND $15, %0" is so much faster than a branch.
This looks much better. Thanks! I will use it in the next version.
>> + end = READ_ONCE(mm->numa_scan_offset);
>> + start = READ_ONCE(mm->numa_scan_starts[i]);
>> + if (start == end)
>> + end = start + MAX_SCAN_WINDOW * (1UL << 22);
>> + for (j = 0; j < NUMA_SCAN_NR_HIST; j++) {
>> + latency = now - READ_ONCE(mm->numa_scan_jiffies[i]);
>> + start = READ_ONCE(mm->numa_scan_starts[i]);
>> + /* Scan pass the end of address space */
>> + if (end < start)
>> + end = TASK_SIZE;
>> + if (addr >= start && addr < end)
>> + return latency;
>> + end = start;
>> + i = i ? i - 1 : NUMA_SCAN_NR_HIST - 1;
>
> i = (i - 1) % NUMA_SCAN_NR_HIST;
Will use this in the next version.
>> + }
>> + /*
>> + * The tracking window isn't large enough, approximate to the
>> + * max latency in the tracking window.
>> + */
>> + return latency;
>> +}
>
>> @@ -2583,6 +2640,19 @@ void task_numa_work(struct callback_head *work)
>> start = 0;
>> vma = mm->mmap;
>> }
>> + idx = mm->numa_scan_idx;
>> + WRITE_ONCE(mm->numa_scan_starts[idx], start);
>> + WRITE_ONCE(mm->numa_scan_jiffies[idx], jiffies);
>> + /*
>> + * Paired with smp_rmb() in should_numa_migrate_memory() to
>> + * update scan range buffer index after update the buffer
>> + * contents.
>> + */
>> + smp_wmb();
>> + if (idx + 1 >= NUMA_SCAN_NR_HIST)
>> + WRITE_ONCE(mm->numa_scan_idx, 0);
>> + else
>> + WRITE_ONCE(mm->numa_scan_idx, idx + 1);
>
> smp_store_release(&mm->nums_scan_idx, idx % NUMA_SCAN_NR_HIST);
Will use this in the next version.
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2019-11-04 2:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-01 7:57 [RFC 00/10] autonuma: Optimize memory placement in memory tiering system Huang, Ying
2019-11-01 7:57 ` [RFC 01/10] autonuma: Fix watermark checking in migrate_balanced_pgdat() Huang, Ying
2019-11-01 11:11 ` Mel Gorman
2019-11-01 7:57 ` [RFC 02/10] autonuma: Reduce cache footprint when scanning page tables Huang, Ying
2019-11-01 11:13 ` Mel Gorman
2019-11-01 7:57 ` [RFC 03/10] autonuma: Add NUMA_BALANCING_MEMORY_TIERING mode Huang, Ying
2019-11-01 7:57 ` [RFC 04/10] autonuma, memory tiering: Rate limit NUMA migration throughput Huang, Ying
2019-11-01 7:57 ` [RFC 05/10] autonuma, memory tiering: Use kswapd to demote cold pages to PMEM Huang, Ying
2019-11-01 7:57 ` [RFC 06/10] autonuma, memory tiering: Skip to scan fastest memory Huang, Ying
2019-11-01 7:57 ` [RFC 07/10] autonuma, memory tiering: Only promote page if accessed twice Huang, Ying
2019-11-01 7:57 ` [RFC 08/10] autonuma, memory tiering: Select hotter pages to promote to fast memory node Huang, Ying
2019-11-01 9:24 ` Peter Zijlstra
2019-11-04 2:41 ` Huang, Ying [this message]
2019-11-04 8:44 ` Peter Zijlstra
2019-11-04 10:13 ` Huang, Ying
2019-11-01 7:57 ` [RFC 09/10] autonuma, memory tiering: Double hot threshold for write hint page fault Huang, Ying
2019-11-01 7:57 ` [RFC 10/10] autonuma, memory tiering: Adjust hot threshold automatically Huang, Ying
2019-11-01 9:31 ` Peter Zijlstra
2019-11-04 6:11 ` Huang, Ying
2019-11-04 8:49 ` Peter Zijlstra
2019-11-04 10:12 ` Huang, Ying
2019-11-21 8:38 ` 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=87k18gcqih.fsf@yhuang-dev.intel.com \
--to=ying.huang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.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.