Message-ID: <20220216163843.5293ff58@canb.auug.org.au>
Date:   Wed, 16 Feb 2022 16:38:43 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     "Huang, Ying" <ying.huang@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: linux-next: manual merge of the akpm-current tree with the tip tree

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  Documentation/admin-guide/sysctl/kernel.rst

between commit:

  3624ba7b5e2a ("sched/numa-balancing: Move some document to make it consistent with the code")

from the tip tree and commit:

  2dc52f4f86f9 ("NUMA balancing: optimize page placement for memory tiering system")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/admin-guide/sysctl/kernel.rst
index 8551aeca1574,59c3b4ce37cd..000000000000
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@@ -609,8 -616,56 +616,14 @@@ being accessed should be migrated to a 
  The unmapping of pages and trapping faults incur additional overhead that
  ideally is offset by improved memory locality but there is no universal
  guarantee. If the target workload is already bound to NUMA nodes then this
 -feature should be disabled. Otherwise, if the system overhead from the
 -feature is too high then the rate the kernel samples for NUMA hinting
 -faults may be controlled by the `numa_balancing_scan_period_min_ms,
 -numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms,
 -numa_balancing_scan_size_mb`_, and numa_balancing_settle_count sysctls.
 +feature should be disabled.
  
+ Or NUMA_BALANCING_MEMORY_TIERING to optimize page placement among
+ different types of memory (represented as different NUMA nodes) to
+ place the hot pages in the fast memory.  This is implemented based on
+ unmapping and page fault too.
 -
 -numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb
 -===============================================================================================================================
 -
 -
 -Automatic NUMA balancing scans tasks address space and unmaps pages to
 -detect if pages are properly placed or if the data should be migrated to a
 -memory node local to where the task is running.  Every "scan delay" the task
 -scans the next "scan size" number of pages in its address space. When the
 -end of the address space is reached the scanner restarts from the beginning.
 -
 -In combination, the "scan delay" and "scan size" determine the scan rate.
 -When "scan delay" decreases, the scan rate increases.  The scan delay and
 -hence the scan rate of every task is adaptive and depends on historical
 -behaviour. If pages are properly placed then the scan delay increases,
 -otherwise the scan delay decreases.  The "scan size" is not adaptive but
 -the higher the "scan size", the higher the scan rate.
 -
 -Higher scan rates incur higher system overhead as page faults must be
 -trapped and potentially data must be migrated. However, the higher the scan
 -rate, the more quickly a tasks memory is migrated to a local node if the
 -workload pattern changes and minimises performance impact due to remote
 -memory accesses. These sysctls control the thresholds for scan delays and
 -the number of pages scanned.
 -
 -``numa_balancing_scan_period_min_ms`` is the minimum time in milliseconds to
 -scan a tasks virtual memory. It effectively controls the maximum scanning
 -rate for each task.
 -
 -``numa_balancing_scan_delay_ms`` is the starting "scan delay" used for a task
 -when it initially forks.
 -
 -``numa_balancing_scan_period_max_ms`` is the maximum time in milliseconds to
 -scan a tasks virtual memory. It effectively controls the minimum scanning
 -rate for each task.
 -
 -``numa_balancing_scan_size_mb`` is how many megabytes worth of pages are
 -scanned for a given scan.
+ 
+ 
  oops_all_cpu_backtrace
  ======================
  

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists