Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1678394 > unrolled thread
| Started by | "Huang, Ying" <ying.huang@intel.com> |
|---|---|
| First post | 2017-06-30 03:50 +0200 |
| Last post | 2017-06-30 10:00 +0200 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH -mm -v2 0/6] mm, swap: VMA based swap readahead "Huang, Ying" <ying.huang@intel.com> - 2017-06-30 03:50 +0200
[PATCH -mm -v2 6/6] mm, swap: Don't use VMA based swap readahead if HDD is used as swap "Huang, Ying" <ying.huang@intel.com> - 2017-06-30 03:50 +0200
Re: [PATCH -mm -v2 0/6] mm, swap: VMA based swap readahead Minchan Kim <minchan@kernel.org> - 2017-06-30 04:30 +0200
Re: [PATCH -mm -v2 0/6] mm, swap: VMA based swap readahead "Huang\, Ying" <ying.huang@intel.com> - 2017-06-30 10:00 +0200
| From | "Huang, Ying" <ying.huang@intel.com> |
|---|---|
| Date | 2017-06-30 03:50 +0200 |
| Subject | [PATCH -mm -v2 0/6] mm, swap: VMA based swap readahead |
| Message-ID | <tXTeh-7bI-9@gated-at.bofh.it> |
The swap readahead is an important mechanism to reduce the swap in latency. Although pure sequential memory access pattern isn't very popular for anonymous memory, the space locality is still considered valid. In the original swap readahead implementation, the consecutive blocks in swap device are readahead based on the global space locality estimation. But the consecutive blocks in swap device just reflect the order of page reclaiming, don't necessarily reflect the access pattern in virtual memory space. And the different tasks in the system may have different access patterns, which makes the global space locality estimation incorrect. In this patchset, when page fault occurs, the virtual pages near the fault address will be readahead instead of the swap slots near the fault swap slot in swap device. This avoid to readahead the unrelated swap slots. At the same time, the swap readahead is changed to work on per-VMA from globally. So that the different access patterns of the different VMAs could be distinguished, and the different readahead policy could be applied accordingly. The original core readahead detection and scaling algorithm is reused, because it is an effect algorithm to detect the space locality. In addition to the swap readahead changes, some new sysfs interface is added to show the efficiency of the readahead algorithm and some other swap statistics. This new implementation will incur more small random read, on SSD, the improved correctness of estimation and readahead target should beat the potential increased overhead, this is also illustrated in the test results below. But on HDD, the overhead may beat the benefit, so the original implementation will be used by default. The test and result is as follow, Common test condition ===================== Test Machine: Xeon E5 v3 (2 sockets, 72 threads, 32G RAM) Swap device: NVMe disk Micro-benchmark with combined access pattern ============================================ vm-scalability, sequential swap test case, 4 processes to eat 50G virtual memory space, repeat the sequential memory writing until 300 seconds. The first round writing will trigger swap out, the following rounds will trigger sequential swap in and out. At the same time, run vm-scalability random swap test case in background, 8 processes to eat 30G virtual memory space, repeat the random memory write until 300 seconds. This will trigger random swap-in in the background. This is a combined workload with sequential and random memory accessing at the same time. The result (for sequential workload) is as follow, Base Optimized ---- --------- throughput 345413 KB/s 414029 KB/s (+19.9%) latency.average 97.14 us 61.06 us (-37.1%) latency.50th 2 us 1 us latency.60th 2 us 1 us latency.70th 98 us 2 us latency.80th 160 us 2 us latency.90th 260 us 217 us latency.95th 346 us 369 us latency.99th 1.34 ms 1.09 ms ra_hit% 52.69% 99.98% The original swap readahead algorithm is confused by the background random access workload, so readahead hit rate is lower. The VMA-base readahead algorithm works much better. Linpack ======= The test memory size is bigger than RAM to trigger swapping. Base Optimized ---- --------- elapsed_time 393.49 s 329.88 s (-16.2%) ra_hit% 86.21% 98.82% The score of base and optimized kernel hasn't visible changes. But the elapsed time reduced and readahead hit rate improved, so the optimized kernel runs better for startup and tear down stages. And the absolute value of readahead hit rate is high, shows that the space locality is still valid in some practical workloads.
[toc] | [next] | [standalone]
| From | "Huang, Ying" <ying.huang@intel.com> |
|---|---|
| Date | 2017-06-30 03:50 +0200 |
| Subject | [PATCH -mm -v2 6/6] mm, swap: Don't use VMA based swap readahead if HDD is used as swap |
| Message-ID | <tXTei-7bI-29@gated-at.bofh.it> |
| In reply to | #1678394 |
From: Huang Ying <ying.huang@intel.com>
VMA based swap readahead will readahead the virtual pages that is
continuous in the virtual address space. While the original swap
readahead will readahead the swap slots that is continuous in the swap
device. Although VMA based swap readahead is more correct for the
swap slots to be readahead, it will trigger more small random
readings, which may cause the performance of HDD (hard disk) to
degrade heavily, and may finally exceed the benefit.
To avoid the issue, in this patch, if the HDD is used as swap, the VMA
based swap readahead will be disabled, and the original swap readahead
will be used instead.
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Shaohua Li <shli@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Tim Chen <tim.c.chen@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
---
include/linux/swap.h | 11 ++++++-----
mm/swapfile.c | 8 +++++++-
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 34fe19f9b4c6..7fa4e4030ddb 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -398,16 +398,17 @@ extern struct page *do_swap_page_readahead(swp_entry_t fentry, gfp_t gfp_mask,
struct vm_fault *vmf,
struct vma_swap_readahead *swap_ra);
-static inline bool swap_use_vma_readahead(void)
-{
- return READ_ONCE(swap_vma_readahead);
-}
-
/* linux/mm/swapfile.c */
extern atomic_long_t nr_swap_pages;
extern long total_swap_pages;
+extern atomic_t nr_rotate_swap;
extern bool has_usable_swap(void);
+static inline bool swap_use_vma_readahead(void)
+{
+ return READ_ONCE(swap_vma_readahead) && !atomic_read(&nr_rotate_swap);
+}
+
/* Swap 50% full? Release swapcache more aggressively.. */
static inline bool vm_swap_full(void)
{
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 6ba4aab2db0b..2685b9951cc1 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -96,6 +96,8 @@ static DECLARE_WAIT_QUEUE_HEAD(proc_poll_wait);
/* Activity counter to indicate that a swapon or swapoff has occurred */
static atomic_t proc_poll_event = ATOMIC_INIT(0);
+atomic_t nr_rotate_swap = ATOMIC_INIT(0);
+
static inline unsigned char swap_count(unsigned char ent)
{
return ent & ~SWAP_HAS_CACHE; /* may include SWAP_HAS_CONT flag */
@@ -2387,6 +2389,9 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile)
if (p->flags & SWP_CONTINUED)
free_swap_count_continuations(p);
+ if (!p->bdev || !blk_queue_nonrot(bdev_get_queue(p->bdev)))
+ atomic_dec(&nr_rotate_swap);
+
mutex_lock(&swapon_mutex);
spin_lock(&swap_lock);
spin_lock(&p->lock);
@@ -2963,7 +2968,8 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
cluster = per_cpu_ptr(p->percpu_cluster, cpu);
cluster_set_null(&cluster->index);
}
- }
+ } else
+ atomic_inc(&nr_rotate_swap);
error = swap_cgroup_swapon(p->type, maxpages);
if (error)
--
2.11.0
[toc] | [prev] | [next] | [standalone]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2017-06-30 04:30 +0200 |
| Message-ID | <tXTQZ-7Ni-5@gated-at.bofh.it> |
| In reply to | #1678394 |
Hi Huang, Ccing Johannes: I don't read this patch yet but I remember Johannes tried VMA-based readahead approach long time ago so he might have good comment. On Fri, Jun 30, 2017 at 09:44:37AM +0800, Huang, Ying wrote: > The swap readahead is an important mechanism to reduce the swap in > latency. Although pure sequential memory access pattern isn't very > popular for anonymous memory, the space locality is still considered > valid. > > In the original swap readahead implementation, the consecutive blocks > in swap device are readahead based on the global space locality > estimation. But the consecutive blocks in swap device just reflect > the order of page reclaiming, don't necessarily reflect the access > pattern in virtual memory space. And the different tasks in the > system may have different access patterns, which makes the global > space locality estimation incorrect. > > In this patchset, when page fault occurs, the virtual pages near the > fault address will be readahead instead of the swap slots near the > fault swap slot in swap device. This avoid to readahead the unrelated > swap slots. At the same time, the swap readahead is changed to work > on per-VMA from globally. So that the different access patterns of > the different VMAs could be distinguished, and the different readahead > policy could be applied accordingly. The original core readahead > detection and scaling algorithm is reused, because it is an effect > algorithm to detect the space locality. > > In addition to the swap readahead changes, some new sysfs interface is > added to show the efficiency of the readahead algorithm and some other > swap statistics. > > This new implementation will incur more small random read, on SSD, the > improved correctness of estimation and readahead target should beat > the potential increased overhead, this is also illustrated in the test > results below. But on HDD, the overhead may beat the benefit, so the > original implementation will be used by default. > > The test and result is as follow, > > Common test condition > ===================== > > Test Machine: Xeon E5 v3 (2 sockets, 72 threads, 32G RAM) > Swap device: NVMe disk > > Micro-benchmark with combined access pattern > ============================================ > > vm-scalability, sequential swap test case, 4 processes to eat 50G > virtual memory space, repeat the sequential memory writing until 300 > seconds. The first round writing will trigger swap out, the following > rounds will trigger sequential swap in and out. > > At the same time, run vm-scalability random swap test case in > background, 8 processes to eat 30G virtual memory space, repeat the > random memory write until 300 seconds. This will trigger random > swap-in in the background. > > This is a combined workload with sequential and random memory > accessing at the same time. The result (for sequential workload) is > as follow, > > Base Optimized > ---- --------- > throughput 345413 KB/s 414029 KB/s (+19.9%) > latency.average 97.14 us 61.06 us (-37.1%) > latency.50th 2 us 1 us > latency.60th 2 us 1 us > latency.70th 98 us 2 us > latency.80th 160 us 2 us > latency.90th 260 us 217 us > latency.95th 346 us 369 us > latency.99th 1.34 ms 1.09 ms > ra_hit% 52.69% 99.98% > > The original swap readahead algorithm is confused by the background > random access workload, so readahead hit rate is lower. The VMA-base > readahead algorithm works much better. > > Linpack > ======= > > The test memory size is bigger than RAM to trigger swapping. > > Base Optimized > ---- --------- > elapsed_time 393.49 s 329.88 s (-16.2%) > ra_hit% 86.21% 98.82% > > The score of base and optimized kernel hasn't visible changes. But > the elapsed time reduced and readahead hit rate improved, so the > optimized kernel runs better for startup and tear down stages. And > the absolute value of readahead hit rate is high, shows that the space > locality is still valid in some practical workloads.
[toc] | [prev] | [next] | [standalone]
| From | "Huang\, Ying" <ying.huang@intel.com> |
|---|---|
| Date | 2017-06-30 10:00 +0200 |
| Message-ID | <tXZ0l-2EL-1@gated-at.bofh.it> |
| In reply to | #1678405 |
Hi, Minchan, Minchan Kim <minchan@kernel.org> writes: > Hi Huang, > > Ccing Johannes: > > I don't read this patch yet but I remember Johannes tried VMA-based > readahead approach long time ago so he might have good comment. Thanks a lot for your information and connecting! Hi, Johannes, Do you have time to take a look at this patchset? Best Regards, Huang, Ying [snip]
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web