[PATCH] mm, swap: Make VMA based swap readahead configurable

[PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

From: Huang Ying <ying.huang@intel.com>

This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
This is more friendly for tiny kernels.  And as pointed to by Minchan
Kim, give people who want to disable the swap readahead an opportunity
to notice the changes to the swap readahead algorithm and the
corresponding knobs.

Cc: Johannes Weiner <hannes@cmpxchg.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>
Suggested-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
---
 include/linux/mm_types.h |  2 ++
 include/linux/swap.h     | 64 +++++++++++++++++++++++++-----------------------
 mm/Kconfig               | 20 +++++++++++++++
 mm/swap_state.c          | 25 ++++++++++++-------
 4 files changed, 72 insertions(+), 39 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 46f4ecf5479a..51da54d8027f 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -336,7 +336,9 @@ struct vm_area_struct {
 	struct file * vm_file;		/* File we map to (can be NULL). */
 	void * vm_private_data;		/* was vm_pte (shared mem) */
 
+#ifdef CONFIG_VMA_SWAP_READAHEAD
 	atomic_long_t swap_readahead_info;
+#endif
 #ifndef CONFIG_MMU
 	struct vm_region *vm_region;	/* NOMMU mapping region */
 #endif
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 8a807292037f..ebc783a23b80 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -278,6 +278,7 @@ struct swap_info_struct {
 #endif
 
 struct vma_swap_readahead {
+#ifdef CONFIG_VMA_SWAP_READAHEAD
 	unsigned short win;
 	unsigned short offset;
 	unsigned short nr_pte;
@@ -286,6 +287,7 @@ struct vma_swap_readahead {
 #else
 	pte_t ptes[SWAP_RA_PTE_CACHE_SIZE];
 #endif
+#endif
 };
 
 /* linux/mm/workingset.c */
@@ -387,7 +389,6 @@ int generic_swapfile_activate(struct swap_info_struct *, struct file *,
 #define SWAP_ADDRESS_SPACE_SHIFT	14
 #define SWAP_ADDRESS_SPACE_PAGES	(1 << SWAP_ADDRESS_SPACE_SHIFT)
 extern struct address_space *swapper_spaces[];
-extern bool swap_vma_readahead;
 #define swap_address_space(entry)			    \
 	(&swapper_spaces[swp_type(entry)][swp_offset(entry) \
 		>> SWAP_ADDRESS_SPACE_SHIFT])
@@ -412,23 +413,12 @@ extern struct page *__read_swap_cache_async(swp_entry_t, gfp_t,
 extern struct page *swapin_readahead(swp_entry_t, gfp_t,
 			struct vm_area_struct *vma, unsigned long addr);
 
-extern struct page *swap_readahead_detect(struct vm_fault *vmf,
-					  struct vma_swap_readahead *swap_ra);
-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);
-
 /* 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)
 {
@@ -518,24 +508,6 @@ static inline struct page *swapin_readahead(swp_entry_t swp, gfp_t gfp_mask,
 	return NULL;
 }
 
-static inline bool swap_use_vma_readahead(void)
-{
-	return false;
-}
-
-static inline struct page *swap_readahead_detect(
-	struct vm_fault *vmf, struct vma_swap_readahead *swap_ra)
-{
-	return NULL;
-}
-
-static inline struct page *do_swap_page_readahead(
-	swp_entry_t fentry, gfp_t gfp_mask,
-	struct vm_fault *vmf, struct vma_swap_readahead *swap_ra)
-{
-	return NULL;
-}
-
 static inline int swap_writepage(struct page *p, struct writeback_control *wbc)
 {
 	return 0;
@@ -662,5 +634,37 @@ static inline bool mem_cgroup_swap_full(struct page *page)
 }
 #endif
 
+#ifdef CONFIG_VMA_SWAP_READAHEAD
+extern bool swap_vma_readahead;
+
+static inline bool swap_use_vma_readahead(void)
+{
+	return READ_ONCE(swap_vma_readahead) && !atomic_read(&nr_rotate_swap);
+}
+extern struct page *swap_readahead_detect(struct vm_fault *vmf,
+					  struct vma_swap_readahead *swap_ra);
+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);
+#else
+static inline bool swap_use_vma_readahead(void)
+{
+	return false;
+}
+
+static inline struct page *swap_readahead_detect(struct vm_fault *vmf,
+				struct vma_swap_readahead *swap_ra)
+{
+	return NULL;
+}
+
+static inline struct page *do_swap_page_readahead(swp_entry_t fentry,
+				gfp_t gfp_mask, struct vm_fault *vmf,
+				struct vma_swap_readahead *swap_ra)
+{
+	return NULL;
+}
+#endif
+
 #endif /* __KERNEL__*/
 #endif /* _LINUX_SWAP_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index 9c4bdddd80c2..e62c8e2e34ef 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -434,6 +434,26 @@ config THP_SWAP
 
 	  For selection by architectures with reasonable THP sizes.
 
+config VMA_SWAP_READAHEAD
+	bool "VMA based swap readahead"
+	depends on SWAP
+	default y
+	help
+	  VMA based swap readahead detects page accessing pattern in a
+	  VMA and adjust the swap readahead window for pages in the
+	  VMA accordingly.  It works better for more complex workload
+	  compared with the original physical swap readahead.
+
+	  It can be controlled via the following sysfs interface,
+
+	    /sys/kernel/mm/swap/vma_ra_enabled
+	    /sys/kernel/mm/swap/vma_ra_max_order
+
+	  If set to no, the original physical swap readahead will be
+	  used.
+
+	  If unsure, say Y to enable VMA based swap readahead.
+
 config	TRANSPARENT_HUGE_PAGECACHE
 	def_bool y
 	depends on TRANSPARENT_HUGEPAGE
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 71ce2d1ccbf7..6d6f6a534bf9 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -37,11 +37,6 @@ static const struct address_space_operations swap_aops = {
 
 struct address_space *swapper_spaces[MAX_SWAPFILES];
 static unsigned int nr_swapper_spaces[MAX_SWAPFILES];
-bool swap_vma_readahead = true;
-
-#define SWAP_RA_MAX_ORDER_DEFAULT	3
-
-static int swap_ra_max_order = SWAP_RA_MAX_ORDER_DEFAULT;
 
 #define SWAP_RA_WIN_SHIFT	(PAGE_SHIFT / 2)
 #define SWAP_RA_HITS_MASK	((1UL << SWAP_RA_WIN_SHIFT) - 1)
@@ -324,8 +319,7 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
 			       unsigned long addr)
 {
 	struct page *page;
-	unsigned long ra_info;
-	int win, hits, readahead;
+	int readahead;
 
 	page = find_get_page(swap_address_space(entry), swp_offset(entry));
 
@@ -335,7 +329,11 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
 		if (unlikely(PageTransCompound(page)))
 			return page;
 		readahead = TestClearPageReadahead(page);
+#ifdef CONFIG_VMA_SWAP_READAHEAD
 		if (vma) {
+			unsigned long ra_info;
+			int win, hits;
+
 			ra_info = GET_SWAP_RA_VAL(vma);
 			win = SWAP_RA_WIN(ra_info);
 			hits = SWAP_RA_HITS(ra_info);
@@ -344,6 +342,7 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
 			atomic_long_set(&vma->swap_readahead_info,
 					SWAP_RA_VAL(addr, win, hits));
 		}
+#endif
 		if (readahead) {
 			count_vm_event(SWAP_RA_HIT);
 			if (!vma)
@@ -625,6 +624,13 @@ void exit_swap_address_space(unsigned int type)
 	kvfree(spaces);
 }
 
+#ifdef CONFIG_VMA_SWAP_READAHEAD
+bool swap_vma_readahead = true;
+
+#define SWAP_RA_MAX_ORDER_DEFAULT	3
+
+static int swap_ra_max_order = SWAP_RA_MAX_ORDER_DEFAULT;
+
 static inline void swap_ra_clamp_pfn(struct vm_area_struct *vma,
 				     unsigned long faddr,
 				     unsigned long lpfn,
@@ -751,8 +757,9 @@ struct page *do_swap_page_readahead(swp_entry_t fentry, gfp_t gfp_mask,
 	return read_swap_cache_async(fentry, gfp_mask, vma, vmf->address,
 				     swap_ra->win == 1);
 }
+#endif /* CONFIG_VMA_SWAP_READAHEAD */
 
-#ifdef CONFIG_SYSFS
+#if defined(CONFIG_SYSFS) && defined(CONFIG_VMA_SWAP_READAHEAD)
 static ssize_t vma_ra_enabled_show(struct kobject *kobj,
 				     struct kobj_attribute *attr, char *buf)
 {
@@ -830,4 +837,4 @@ static int __init swap_init_sysfs(void)
 	return err;
 }
 subsys_initcall(swap_init_sysfs);
-#endif
+#endif /* defined(CONFIG_SYSFS) && defined(CONFIG_VMA_SWAP_READAHEAD) */
-- 
2.14.1

[PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

From: Huang Ying <ying.huang@intel.com>

This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
This is more friendly for tiny kernels.  And as pointed to by Minchan
Kim, give people who want to disable the swap readahead an opportunity
to notice the changes to the swap readahead algorithm and the
corresponding knobs.

Cc: Johannes Weiner <hannes@cmpxchg.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>
Suggested-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
---
 include/linux/mm_types.h |  2 ++
 include/linux/swap.h     | 64 +++++++++++++++++++++++++-----------------------
 mm/Kconfig               | 20 +++++++++++++++
 mm/swap_state.c          | 25 ++++++++++++-------
 4 files changed, 72 insertions(+), 39 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 46f4ecf5479a..51da54d8027f 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -336,7 +336,9 @@ struct vm_area_struct {
 	struct file * vm_file;		/* File we map to (can be NULL). */
 	void * vm_private_data;		/* was vm_pte (shared mem) */
 
+#ifdef CONFIG_VMA_SWAP_READAHEAD
 	atomic_long_t swap_readahead_info;
+#endif
 #ifndef CONFIG_MMU
 	struct vm_region *vm_region;	/* NOMMU mapping region */
 #endif
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 8a807292037f..ebc783a23b80 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -278,6 +278,7 @@ struct swap_info_struct {
 #endif
 
 struct vma_swap_readahead {
+#ifdef CONFIG_VMA_SWAP_READAHEAD
 	unsigned short win;
 	unsigned short offset;
 	unsigned short nr_pte;
@@ -286,6 +287,7 @@ struct vma_swap_readahead {
 #else
 	pte_t ptes[SWAP_RA_PTE_CACHE_SIZE];
 #endif
+#endif
 };
 
 /* linux/mm/workingset.c */
@@ -387,7 +389,6 @@ int generic_swapfile_activate(struct swap_info_struct *, struct file *,
 #define SWAP_ADDRESS_SPACE_SHIFT	14
 #define SWAP_ADDRESS_SPACE_PAGES	(1 << SWAP_ADDRESS_SPACE_SHIFT)
 extern struct address_space *swapper_spaces[];
-extern bool swap_vma_readahead;
 #define swap_address_space(entry)			    \
 	(&swapper_spaces[swp_type(entry)][swp_offset(entry) \
 		>> SWAP_ADDRESS_SPACE_SHIFT])
@@ -412,23 +413,12 @@ extern struct page *__read_swap_cache_async(swp_entry_t, gfp_t,
 extern struct page *swapin_readahead(swp_entry_t, gfp_t,
 			struct vm_area_struct *vma, unsigned long addr);
 
-extern struct page *swap_readahead_detect(struct vm_fault *vmf,
-					  struct vma_swap_readahead *swap_ra);
-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);
-
 /* 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)
 {
@@ -518,24 +508,6 @@ static inline struct page *swapin_readahead(swp_entry_t swp, gfp_t gfp_mask,
 	return NULL;
 }
 
-static inline bool swap_use_vma_readahead(void)
-{
-	return false;
-}
-
-static inline struct page *swap_readahead_detect(
-	struct vm_fault *vmf, struct vma_swap_readahead *swap_ra)
-{
-	return NULL;
-}
-
-static inline struct page *do_swap_page_readahead(
-	swp_entry_t fentry, gfp_t gfp_mask,
-	struct vm_fault *vmf, struct vma_swap_readahead *swap_ra)
-{
-	return NULL;
-}
-
 static inline int swap_writepage(struct page *p, struct writeback_control *wbc)
 {
 	return 0;
@@ -662,5 +634,37 @@ static inline bool mem_cgroup_swap_full(struct page *page)
 }
 #endif
 
+#ifdef CONFIG_VMA_SWAP_READAHEAD
+extern bool swap_vma_readahead;
+
+static inline bool swap_use_vma_readahead(void)
+{
+	return READ_ONCE(swap_vma_readahead) && !atomic_read(&nr_rotate_swap);
+}
+extern struct page *swap_readahead_detect(struct vm_fault *vmf,
+					  struct vma_swap_readahead *swap_ra);
+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);
+#else
+static inline bool swap_use_vma_readahead(void)
+{
+	return false;
+}
+
+static inline struct page *swap_readahead_detect(struct vm_fault *vmf,
+				struct vma_swap_readahead *swap_ra)
+{
+	return NULL;
+}
+
+static inline struct page *do_swap_page_readahead(swp_entry_t fentry,
+				gfp_t gfp_mask, struct vm_fault *vmf,
+				struct vma_swap_readahead *swap_ra)
+{
+	return NULL;
+}
+#endif
+
 #endif /* __KERNEL__*/
 #endif /* _LINUX_SWAP_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index 9c4bdddd80c2..e62c8e2e34ef 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -434,6 +434,26 @@ config THP_SWAP
 
 	  For selection by architectures with reasonable THP sizes.
 
+config VMA_SWAP_READAHEAD
+	bool "VMA based swap readahead"
+	depends on SWAP
+	default y
+	help
+	  VMA based swap readahead detects page accessing pattern in a
+	  VMA and adjust the swap readahead window for pages in the
+	  VMA accordingly.  It works better for more complex workload
+	  compared with the original physical swap readahead.
+
+	  It can be controlled via the following sysfs interface,
+
+	    /sys/kernel/mm/swap/vma_ra_enabled
+	    /sys/kernel/mm/swap/vma_ra_max_order
+
+	  If set to no, the original physical swap readahead will be
+	  used.
+
+	  If unsure, say Y to enable VMA based swap readahead.
+
 config	TRANSPARENT_HUGE_PAGECACHE
 	def_bool y
 	depends on TRANSPARENT_HUGEPAGE
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 71ce2d1ccbf7..6d6f6a534bf9 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -37,11 +37,6 @@ static const struct address_space_operations swap_aops = {
 
 struct address_space *swapper_spaces[MAX_SWAPFILES];
 static unsigned int nr_swapper_spaces[MAX_SWAPFILES];
-bool swap_vma_readahead = true;
-
-#define SWAP_RA_MAX_ORDER_DEFAULT	3
-
-static int swap_ra_max_order = SWAP_RA_MAX_ORDER_DEFAULT;
 
 #define SWAP_RA_WIN_SHIFT	(PAGE_SHIFT / 2)
 #define SWAP_RA_HITS_MASK	((1UL << SWAP_RA_WIN_SHIFT) - 1)
@@ -324,8 +319,7 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
 			       unsigned long addr)
 {
 	struct page *page;
-	unsigned long ra_info;
-	int win, hits, readahead;
+	int readahead;
 
 	page = find_get_page(swap_address_space(entry), swp_offset(entry));
 
@@ -335,7 +329,11 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
 		if (unlikely(PageTransCompound(page)))
 			return page;
 		readahead = TestClearPageReadahead(page);
+#ifdef CONFIG_VMA_SWAP_READAHEAD
 		if (vma) {
+			unsigned long ra_info;
+			int win, hits;
+
 			ra_info = GET_SWAP_RA_VAL(vma);
 			win = SWAP_RA_WIN(ra_info);
 			hits = SWAP_RA_HITS(ra_info);
@@ -344,6 +342,7 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
 			atomic_long_set(&vma->swap_readahead_info,
 					SWAP_RA_VAL(addr, win, hits));
 		}
+#endif
 		if (readahead) {
 			count_vm_event(SWAP_RA_HIT);
 			if (!vma)
@@ -625,6 +624,13 @@ void exit_swap_address_space(unsigned int type)
 	kvfree(spaces);
 }
 
+#ifdef CONFIG_VMA_SWAP_READAHEAD
+bool swap_vma_readahead = true;
+
+#define SWAP_RA_MAX_ORDER_DEFAULT	3
+
+static int swap_ra_max_order = SWAP_RA_MAX_ORDER_DEFAULT;
+
 static inline void swap_ra_clamp_pfn(struct vm_area_struct *vma,
 				     unsigned long faddr,
 				     unsigned long lpfn,
@@ -751,8 +757,9 @@ struct page *do_swap_page_readahead(swp_entry_t fentry, gfp_t gfp_mask,
 	return read_swap_cache_async(fentry, gfp_mask, vma, vmf->address,
 				     swap_ra->win == 1);
 }
+#endif /* CONFIG_VMA_SWAP_READAHEAD */
 
-#ifdef CONFIG_SYSFS
+#if defined(CONFIG_SYSFS) && defined(CONFIG_VMA_SWAP_READAHEAD)
 static ssize_t vma_ra_enabled_show(struct kobject *kobj,
 				     struct kobj_attribute *attr, char *buf)
 {
@@ -830,4 +837,4 @@ static int __init swap_init_sysfs(void)
 	return err;
 }
 subsys_initcall(swap_init_sysfs);
-#endif
+#endif /* defined(CONFIG_SYSFS) && defined(CONFIG_VMA_SWAP_READAHEAD) */
-- 
2.14.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

Hi Huang,

On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
> From: Huang Ying <ying.huang@intel.com>
> 
> This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> This is more friendly for tiny kernels.  And as pointed to by Minchan
> Kim, give people who want to disable the swap readahead an opportunity
> to notice the changes to the swap readahead algorithm and the
> corresponding knobs.
> 
> Cc: Johannes Weiner <hannes@cmpxchg.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>
> Suggested-by: Minchan Kim <minchan@kernel.org>
> Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
> ---
>  include/linux/mm_types.h |  2 ++
>  include/linux/swap.h     | 64 +++++++++++++++++++++++++-----------------------
>  mm/Kconfig               | 20 +++++++++++++++
>  mm/swap_state.c          | 25 ++++++++++++-------
>  4 files changed, 72 insertions(+), 39 deletions(-)
> 
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 46f4ecf5479a..51da54d8027f 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -336,7 +336,9 @@ struct vm_area_struct {
>  	struct file * vm_file;		/* File we map to (can be NULL). */
>  	void * vm_private_data;		/* was vm_pte (shared mem) */
>  
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
>  	atomic_long_t swap_readahead_info;
> +#endif
>  #ifndef CONFIG_MMU
>  	struct vm_region *vm_region;	/* NOMMU mapping region */
>  #endif
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 8a807292037f..ebc783a23b80 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -278,6 +278,7 @@ struct swap_info_struct {
>  #endif
>  
>  struct vma_swap_readahead {
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
>  	unsigned short win;
>  	unsigned short offset;
>  	unsigned short nr_pte;
> @@ -286,6 +287,7 @@ struct vma_swap_readahead {
>  #else
>  	pte_t ptes[SWAP_RA_PTE_CACHE_SIZE];
>  #endif
> +#endif
>  };
>  
>  /* linux/mm/workingset.c */
> @@ -387,7 +389,6 @@ int generic_swapfile_activate(struct swap_info_struct *, struct file *,
>  #define SWAP_ADDRESS_SPACE_SHIFT	14
>  #define SWAP_ADDRESS_SPACE_PAGES	(1 << SWAP_ADDRESS_SPACE_SHIFT)
>  extern struct address_space *swapper_spaces[];
> -extern bool swap_vma_readahead;
>  #define swap_address_space(entry)			    \
>  	(&swapper_spaces[swp_type(entry)][swp_offset(entry) \
>  		>> SWAP_ADDRESS_SPACE_SHIFT])
> @@ -412,23 +413,12 @@ extern struct page *__read_swap_cache_async(swp_entry_t, gfp_t,
>  extern struct page *swapin_readahead(swp_entry_t, gfp_t,
>  			struct vm_area_struct *vma, unsigned long addr);
>  
> -extern struct page *swap_readahead_detect(struct vm_fault *vmf,
> -					  struct vma_swap_readahead *swap_ra);
> -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);
> -
>  /* 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)
>  {
> @@ -518,24 +508,6 @@ static inline struct page *swapin_readahead(swp_entry_t swp, gfp_t gfp_mask,
>  	return NULL;
>  }
>  
> -static inline bool swap_use_vma_readahead(void)
> -{
> -	return false;
> -}
> -
> -static inline struct page *swap_readahead_detect(
> -	struct vm_fault *vmf, struct vma_swap_readahead *swap_ra)
> -{
> -	return NULL;
> -}
> -
> -static inline struct page *do_swap_page_readahead(
> -	swp_entry_t fentry, gfp_t gfp_mask,
> -	struct vm_fault *vmf, struct vma_swap_readahead *swap_ra)
> -{
> -	return NULL;
> -}
> -
>  static inline int swap_writepage(struct page *p, struct writeback_control *wbc)
>  {
>  	return 0;
> @@ -662,5 +634,37 @@ static inline bool mem_cgroup_swap_full(struct page *page)
>  }
>  #endif
>  
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
> +extern bool swap_vma_readahead;
> +
> +static inline bool swap_use_vma_readahead(void)
> +{
> +	return READ_ONCE(swap_vma_readahead) && !atomic_read(&nr_rotate_swap);
> +}
> +extern struct page *swap_readahead_detect(struct vm_fault *vmf,
> +					  struct vma_swap_readahead *swap_ra);
> +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);
> +#else
> +static inline bool swap_use_vma_readahead(void)
> +{
> +	return false;
> +}
> +
> +static inline struct page *swap_readahead_detect(struct vm_fault *vmf,
> +				struct vma_swap_readahead *swap_ra)
> +{
> +	return NULL;
> +}
> +
> +static inline struct page *do_swap_page_readahead(swp_entry_t fentry,
> +				gfp_t gfp_mask, struct vm_fault *vmf,
> +				struct vma_swap_readahead *swap_ra)
> +{
> +	return NULL;
> +}
> +#endif
> +
>  #endif /* __KERNEL__*/
>  #endif /* _LINUX_SWAP_H */
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 9c4bdddd80c2..e62c8e2e34ef 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -434,6 +434,26 @@ config THP_SWAP
>  
>  	  For selection by architectures with reasonable THP sizes.
>  
> +config VMA_SWAP_READAHEAD
> +	bool "VMA based swap readahead"
> +	depends on SWAP
> +	default y
> +	help
> +	  VMA based swap readahead detects page accessing pattern in a
> +	  VMA and adjust the swap readahead window for pages in the
> +	  VMA accordingly.  It works better for more complex workload
> +	  compared with the original physical swap readahead.
> +
> +	  It can be controlled via the following sysfs interface,
> +
> +	    /sys/kernel/mm/swap/vma_ra_enabled
> +	    /sys/kernel/mm/swap/vma_ra_max_order

It might be better to discuss in other thread but if you mention new
interface here again, I will discuss it here.

We are creating new ABI in here so I want to ask question in here.

Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
swap readahead knob? Reusing such common/consistent knob would be better
than adding new separate konb.

> +
> +	  If set to no, the original physical swap readahead will be
> +	  used.

In here, could you point out kindly somewhere where describes two
readahead algorithm in the system?

I don't mean we should explain how it works. Rather than, there are
two parallel algorithm in swap readahead.

Anonymous memory works based on VMA while shm works based on physical
block. There are working separately on parallel. Each of knobs are
vma_ra_max_order and page-cluster, blah, blah.

> +
> +	  If unsure, say Y to enable VMA based swap readahead.
> +
>  config	TRANSPARENT_HUGE_PAGECACHE
>  	def_bool y
>  	depends on TRANSPARENT_HUGEPAGE
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index 71ce2d1ccbf7..6d6f6a534bf9 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -37,11 +37,6 @@ static const struct address_space_operations swap_aops = {
>  
>  struct address_space *swapper_spaces[MAX_SWAPFILES];
>  static unsigned int nr_swapper_spaces[MAX_SWAPFILES];
> -bool swap_vma_readahead = true;
> -
> -#define SWAP_RA_MAX_ORDER_DEFAULT	3
> -
> -static int swap_ra_max_order = SWAP_RA_MAX_ORDER_DEFAULT;
>  
>  #define SWAP_RA_WIN_SHIFT	(PAGE_SHIFT / 2)
>  #define SWAP_RA_HITS_MASK	((1UL << SWAP_RA_WIN_SHIFT) - 1)
> @@ -324,8 +319,7 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
>  			       unsigned long addr)
>  {
>  	struct page *page;
> -	unsigned long ra_info;
> -	int win, hits, readahead;
> +	int readahead;
>  
>  	page = find_get_page(swap_address_space(entry), swp_offset(entry));
>  
> @@ -335,7 +329,11 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
>  		if (unlikely(PageTransCompound(page)))
>  			return page;
>  		readahead = TestClearPageReadahead(page);
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
>  		if (vma) {
> +			unsigned long ra_info;
> +			int win, hits;
> +
>  			ra_info = GET_SWAP_RA_VAL(vma);
>  			win = SWAP_RA_WIN(ra_info);
>  			hits = SWAP_RA_HITS(ra_info);
> @@ -344,6 +342,7 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
>  			atomic_long_set(&vma->swap_readahead_info,
>  					SWAP_RA_VAL(addr, win, hits));
>  		}
> +#endif
>  		if (readahead) {
>  			count_vm_event(SWAP_RA_HIT);
>  			if (!vma)
> @@ -625,6 +624,13 @@ void exit_swap_address_space(unsigned int type)
>  	kvfree(spaces);
>  }
>  
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
> +bool swap_vma_readahead = true;
> +
> +#define SWAP_RA_MAX_ORDER_DEFAULT	3
> +
> +static int swap_ra_max_order = SWAP_RA_MAX_ORDER_DEFAULT;
> +
>  static inline void swap_ra_clamp_pfn(struct vm_area_struct *vma,
>  				     unsigned long faddr,
>  				     unsigned long lpfn,
> @@ -751,8 +757,9 @@ struct page *do_swap_page_readahead(swp_entry_t fentry, gfp_t gfp_mask,
>  	return read_swap_cache_async(fentry, gfp_mask, vma, vmf->address,
>  				     swap_ra->win == 1);
>  }
> +#endif /* CONFIG_VMA_SWAP_READAHEAD */
>  
> -#ifdef CONFIG_SYSFS
> +#if defined(CONFIG_SYSFS) && defined(CONFIG_VMA_SWAP_READAHEAD)
>  static ssize_t vma_ra_enabled_show(struct kobject *kobj,
>  				     struct kobj_attribute *attr, char *buf)
>  {
> @@ -830,4 +837,4 @@ static int __init swap_init_sysfs(void)
>  	return err;
>  }
>  subsys_initcall(swap_init_sysfs);
> -#endif
> +#endif /* defined(CONFIG_SYSFS) && defined(CONFIG_VMA_SWAP_READAHEAD) */
> -- 
> 2.14.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

Hi Huang,

On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
> From: Huang Ying <ying.huang@intel.com>
> 
> This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> This is more friendly for tiny kernels.  And as pointed to by Minchan
> Kim, give people who want to disable the swap readahead an opportunity
> to notice the changes to the swap readahead algorithm and the
> corresponding knobs.
> 
> Cc: Johannes Weiner <hannes@cmpxchg.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>
> Suggested-by: Minchan Kim <minchan@kernel.org>
> Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
> ---
>  include/linux/mm_types.h |  2 ++
>  include/linux/swap.h     | 64 +++++++++++++++++++++++++-----------------------
>  mm/Kconfig               | 20 +++++++++++++++
>  mm/swap_state.c          | 25 ++++++++++++-------
>  4 files changed, 72 insertions(+), 39 deletions(-)
> 
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 46f4ecf5479a..51da54d8027f 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -336,7 +336,9 @@ struct vm_area_struct {
>  	struct file * vm_file;		/* File we map to (can be NULL). */
>  	void * vm_private_data;		/* was vm_pte (shared mem) */
>  
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
>  	atomic_long_t swap_readahead_info;
> +#endif
>  #ifndef CONFIG_MMU
>  	struct vm_region *vm_region;	/* NOMMU mapping region */
>  #endif
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 8a807292037f..ebc783a23b80 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -278,6 +278,7 @@ struct swap_info_struct {
>  #endif
>  
>  struct vma_swap_readahead {
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
>  	unsigned short win;
>  	unsigned short offset;
>  	unsigned short nr_pte;
> @@ -286,6 +287,7 @@ struct vma_swap_readahead {
>  #else
>  	pte_t ptes[SWAP_RA_PTE_CACHE_SIZE];
>  #endif
> +#endif
>  };
>  
>  /* linux/mm/workingset.c */
> @@ -387,7 +389,6 @@ int generic_swapfile_activate(struct swap_info_struct *, struct file *,
>  #define SWAP_ADDRESS_SPACE_SHIFT	14
>  #define SWAP_ADDRESS_SPACE_PAGES	(1 << SWAP_ADDRESS_SPACE_SHIFT)
>  extern struct address_space *swapper_spaces[];
> -extern bool swap_vma_readahead;
>  #define swap_address_space(entry)			    \
>  	(&swapper_spaces[swp_type(entry)][swp_offset(entry) \
>  		>> SWAP_ADDRESS_SPACE_SHIFT])
> @@ -412,23 +413,12 @@ extern struct page *__read_swap_cache_async(swp_entry_t, gfp_t,
>  extern struct page *swapin_readahead(swp_entry_t, gfp_t,
>  			struct vm_area_struct *vma, unsigned long addr);
>  
> -extern struct page *swap_readahead_detect(struct vm_fault *vmf,
> -					  struct vma_swap_readahead *swap_ra);
> -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);
> -
>  /* 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)
>  {
> @@ -518,24 +508,6 @@ static inline struct page *swapin_readahead(swp_entry_t swp, gfp_t gfp_mask,
>  	return NULL;
>  }
>  
> -static inline bool swap_use_vma_readahead(void)
> -{
> -	return false;
> -}
> -
> -static inline struct page *swap_readahead_detect(
> -	struct vm_fault *vmf, struct vma_swap_readahead *swap_ra)
> -{
> -	return NULL;
> -}
> -
> -static inline struct page *do_swap_page_readahead(
> -	swp_entry_t fentry, gfp_t gfp_mask,
> -	struct vm_fault *vmf, struct vma_swap_readahead *swap_ra)
> -{
> -	return NULL;
> -}
> -
>  static inline int swap_writepage(struct page *p, struct writeback_control *wbc)
>  {
>  	return 0;
> @@ -662,5 +634,37 @@ static inline bool mem_cgroup_swap_full(struct page *page)
>  }
>  #endif
>  
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
> +extern bool swap_vma_readahead;
> +
> +static inline bool swap_use_vma_readahead(void)
> +{
> +	return READ_ONCE(swap_vma_readahead) && !atomic_read(&nr_rotate_swap);
> +}
> +extern struct page *swap_readahead_detect(struct vm_fault *vmf,
> +					  struct vma_swap_readahead *swap_ra);
> +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);
> +#else
> +static inline bool swap_use_vma_readahead(void)
> +{
> +	return false;
> +}
> +
> +static inline struct page *swap_readahead_detect(struct vm_fault *vmf,
> +				struct vma_swap_readahead *swap_ra)
> +{
> +	return NULL;
> +}
> +
> +static inline struct page *do_swap_page_readahead(swp_entry_t fentry,
> +				gfp_t gfp_mask, struct vm_fault *vmf,
> +				struct vma_swap_readahead *swap_ra)
> +{
> +	return NULL;
> +}
> +#endif
> +
>  #endif /* __KERNEL__*/
>  #endif /* _LINUX_SWAP_H */
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 9c4bdddd80c2..e62c8e2e34ef 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -434,6 +434,26 @@ config THP_SWAP
>  
>  	  For selection by architectures with reasonable THP sizes.
>  
> +config VMA_SWAP_READAHEAD
> +	bool "VMA based swap readahead"
> +	depends on SWAP
> +	default y
> +	help
> +	  VMA based swap readahead detects page accessing pattern in a
> +	  VMA and adjust the swap readahead window for pages in the
> +	  VMA accordingly.  It works better for more complex workload
> +	  compared with the original physical swap readahead.
> +
> +	  It can be controlled via the following sysfs interface,
> +
> +	    /sys/kernel/mm/swap/vma_ra_enabled
> +	    /sys/kernel/mm/swap/vma_ra_max_order

It might be better to discuss in other thread but if you mention new
interface here again, I will discuss it here.

We are creating new ABI in here so I want to ask question in here.

Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
swap readahead knob? Reusing such common/consistent knob would be better
than adding new separate konb.

> +
> +	  If set to no, the original physical swap readahead will be
> +	  used.

In here, could you point out kindly somewhere where describes two
readahead algorithm in the system?

I don't mean we should explain how it works. Rather than, there are
two parallel algorithm in swap readahead.

Anonymous memory works based on VMA while shm works based on physical
block. There are working separately on parallel. Each of knobs are
vma_ra_max_order and page-cluster, blah, blah.

> +
> +	  If unsure, say Y to enable VMA based swap readahead.
> +
>  config	TRANSPARENT_HUGE_PAGECACHE
>  	def_bool y
>  	depends on TRANSPARENT_HUGEPAGE
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index 71ce2d1ccbf7..6d6f6a534bf9 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -37,11 +37,6 @@ static const struct address_space_operations swap_aops = {
>  
>  struct address_space *swapper_spaces[MAX_SWAPFILES];
>  static unsigned int nr_swapper_spaces[MAX_SWAPFILES];
> -bool swap_vma_readahead = true;
> -
> -#define SWAP_RA_MAX_ORDER_DEFAULT	3
> -
> -static int swap_ra_max_order = SWAP_RA_MAX_ORDER_DEFAULT;
>  
>  #define SWAP_RA_WIN_SHIFT	(PAGE_SHIFT / 2)
>  #define SWAP_RA_HITS_MASK	((1UL << SWAP_RA_WIN_SHIFT) - 1)
> @@ -324,8 +319,7 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
>  			       unsigned long addr)
>  {
>  	struct page *page;
> -	unsigned long ra_info;
> -	int win, hits, readahead;
> +	int readahead;
>  
>  	page = find_get_page(swap_address_space(entry), swp_offset(entry));
>  
> @@ -335,7 +329,11 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
>  		if (unlikely(PageTransCompound(page)))
>  			return page;
>  		readahead = TestClearPageReadahead(page);
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
>  		if (vma) {
> +			unsigned long ra_info;
> +			int win, hits;
> +
>  			ra_info = GET_SWAP_RA_VAL(vma);
>  			win = SWAP_RA_WIN(ra_info);
>  			hits = SWAP_RA_HITS(ra_info);
> @@ -344,6 +342,7 @@ struct page *lookup_swap_cache(swp_entry_t entry, struct vm_area_struct *vma,
>  			atomic_long_set(&vma->swap_readahead_info,
>  					SWAP_RA_VAL(addr, win, hits));
>  		}
> +#endif
>  		if (readahead) {
>  			count_vm_event(SWAP_RA_HIT);
>  			if (!vma)
> @@ -625,6 +624,13 @@ void exit_swap_address_space(unsigned int type)
>  	kvfree(spaces);
>  }
>  
> +#ifdef CONFIG_VMA_SWAP_READAHEAD
> +bool swap_vma_readahead = true;
> +
> +#define SWAP_RA_MAX_ORDER_DEFAULT	3
> +
> +static int swap_ra_max_order = SWAP_RA_MAX_ORDER_DEFAULT;
> +
>  static inline void swap_ra_clamp_pfn(struct vm_area_struct *vma,
>  				     unsigned long faddr,
>  				     unsigned long lpfn,
> @@ -751,8 +757,9 @@ struct page *do_swap_page_readahead(swp_entry_t fentry, gfp_t gfp_mask,
>  	return read_swap_cache_async(fentry, gfp_mask, vma, vmf->address,
>  				     swap_ra->win == 1);
>  }
> +#endif /* CONFIG_VMA_SWAP_READAHEAD */
>  
> -#ifdef CONFIG_SYSFS
> +#if defined(CONFIG_SYSFS) && defined(CONFIG_VMA_SWAP_READAHEAD)
>  static ssize_t vma_ra_enabled_show(struct kobject *kobj,
>  				     struct kobj_attribute *attr, char *buf)
>  {
> @@ -830,4 +837,4 @@ static int __init swap_init_sysfs(void)
>  	return err;
>  }
>  subsys_initcall(swap_init_sysfs);
> -#endif
> +#endif /* defined(CONFIG_SYSFS) && defined(CONFIG_VMA_SWAP_READAHEAD) */
> -- 
> 2.14.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

Hi, Minchan,

Minchan Kim <minchan@kernel.org> writes:

> Hi Huang,
>
> On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
>> From: Huang Ying <ying.huang@intel.com>

[snip]

>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 9c4bdddd80c2..e62c8e2e34ef 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -434,6 +434,26 @@ config THP_SWAP
>>  
>>  	  For selection by architectures with reasonable THP sizes.
>>  
>> +config VMA_SWAP_READAHEAD
>> +	bool "VMA based swap readahead"
>> +	depends on SWAP
>> +	default y
>> +	help
>> +	  VMA based swap readahead detects page accessing pattern in a
>> +	  VMA and adjust the swap readahead window for pages in the
>> +	  VMA accordingly.  It works better for more complex workload
>> +	  compared with the original physical swap readahead.
>> +
>> +	  It can be controlled via the following sysfs interface,
>> +
>> +	    /sys/kernel/mm/swap/vma_ra_enabled
>> +	    /sys/kernel/mm/swap/vma_ra_max_order
>
> It might be better to discuss in other thread but if you mention new
> interface here again, I will discuss it here.
>
> We are creating new ABI in here so I want to ask question in here.
>
> Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
> swap readahead knob? Reusing such common/consistent knob would be better
> than adding new separate konb.

The problem is that the configuration of VMA based swap readahead is
global instead of block device specific.  And because it works in
virtual way, that is, the swap blocks on the different block devices may
be readahead together.  It's a little hard to use the block device
specific configuration.

>> +
>> +	  If set to no, the original physical swap readahead will be
>> +	  used.
>
> In here, could you point out kindly somewhere where describes two
> readahead algorithm in the system?
>
> I don't mean we should explain how it works. Rather than, there are
> two parallel algorithm in swap readahead.
>
> Anonymous memory works based on VMA while shm works based on physical
> block. There are working separately on parallel. Each of knobs are
> vma_ra_max_order and page-cluster, blah, blah.

Sure.  I will add some description about that somewhere.

>> +
>> +	  If unsure, say Y to enable VMA based swap readahead.
>> +
>>  config	TRANSPARENT_HUGE_PAGECACHE
>>  	def_bool y
>>  	depends on TRANSPARENT_HUGEPAGE

[snip]

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

Hi, Minchan,

Minchan Kim <minchan@kernel.org> writes:

> Hi Huang,
>
> On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
>> From: Huang Ying <ying.huang@intel.com>

[snip]

>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 9c4bdddd80c2..e62c8e2e34ef 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -434,6 +434,26 @@ config THP_SWAP
>>  
>>  	  For selection by architectures with reasonable THP sizes.
>>  
>> +config VMA_SWAP_READAHEAD
>> +	bool "VMA based swap readahead"
>> +	depends on SWAP
>> +	default y
>> +	help
>> +	  VMA based swap readahead detects page accessing pattern in a
>> +	  VMA and adjust the swap readahead window for pages in the
>> +	  VMA accordingly.  It works better for more complex workload
>> +	  compared with the original physical swap readahead.
>> +
>> +	  It can be controlled via the following sysfs interface,
>> +
>> +	    /sys/kernel/mm/swap/vma_ra_enabled
>> +	    /sys/kernel/mm/swap/vma_ra_max_order
>
> It might be better to discuss in other thread but if you mention new
> interface here again, I will discuss it here.
>
> We are creating new ABI in here so I want to ask question in here.
>
> Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
> swap readahead knob? Reusing such common/consistent knob would be better
> than adding new separate konb.

The problem is that the configuration of VMA based swap readahead is
global instead of block device specific.  And because it works in
virtual way, that is, the swap blocks on the different block devices may
be readahead together.  It's a little hard to use the block device
specific configuration.

>> +
>> +	  If set to no, the original physical swap readahead will be
>> +	  used.
>
> In here, could you point out kindly somewhere where describes two
> readahead algorithm in the system?
>
> I don't mean we should explain how it works. Rather than, there are
> two parallel algorithm in swap readahead.
>
> Anonymous memory works based on VMA while shm works based on physical
> block. There are working separately on parallel. Each of knobs are
> vma_ra_max_order and page-cluster, blah, blah.

Sure.  I will add some description about that somewhere.

>> +
>> +	  If unsure, say Y to enable VMA based swap readahead.
>> +
>>  config	TRANSPARENT_HUGE_PAGECACHE
>>  	def_bool y
>>  	depends on TRANSPARENT_HUGEPAGE

[snip]

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Mon, Sep 25, 2017 at 01:54:42PM +0800, Huang, Ying wrote:
> Hi, Minchan,
> 
> Minchan Kim <minchan@kernel.org> writes:
> 
> > Hi Huang,
> >
> > On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
> >> From: Huang Ying <ying.huang@intel.com>
> 
> [snip]
> 
> >> diff --git a/mm/Kconfig b/mm/Kconfig
> >> index 9c4bdddd80c2..e62c8e2e34ef 100644
> >> --- a/mm/Kconfig
> >> +++ b/mm/Kconfig
> >> @@ -434,6 +434,26 @@ config THP_SWAP
> >>  
> >>  	  For selection by architectures with reasonable THP sizes.
> >>  
> >> +config VMA_SWAP_READAHEAD
> >> +	bool "VMA based swap readahead"
> >> +	depends on SWAP
> >> +	default y
> >> +	help
> >> +	  VMA based swap readahead detects page accessing pattern in a
> >> +	  VMA and adjust the swap readahead window for pages in the
> >> +	  VMA accordingly.  It works better for more complex workload
> >> +	  compared with the original physical swap readahead.
> >> +
> >> +	  It can be controlled via the following sysfs interface,
> >> +
> >> +	    /sys/kernel/mm/swap/vma_ra_enabled
> >> +	    /sys/kernel/mm/swap/vma_ra_max_order
> >
> > It might be better to discuss in other thread but if you mention new
> > interface here again, I will discuss it here.
> >
> > We are creating new ABI in here so I want to ask question in here.
> >
> > Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
> > swap readahead knob? Reusing such common/consistent knob would be better
> > than adding new separate konb.
> 
> The problem is that the configuration of VMA based swap readahead is
> global instead of block device specific.  And because it works in
> virtual way, that is, the swap blocks on the different block devices may
> be readahead together.  It's a little hard to use the block device
> specific configuration.

Fair enough. page-cluster from the beginning should have been like that
instead of vma_ra_max_order.

One more questions: Do we need separate vma_ra_enable?

Can't we disable it via echo 0 > /sys/kernel/mm/swap/vma_ra_max_order
like page-cluster?

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Mon, Sep 25, 2017 at 01:54:42PM +0800, Huang, Ying wrote:
> Hi, Minchan,
> 
> Minchan Kim <minchan@kernel.org> writes:
> 
> > Hi Huang,
> >
> > On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
> >> From: Huang Ying <ying.huang@intel.com>
> 
> [snip]
> 
> >> diff --git a/mm/Kconfig b/mm/Kconfig
> >> index 9c4bdddd80c2..e62c8e2e34ef 100644
> >> --- a/mm/Kconfig
> >> +++ b/mm/Kconfig
> >> @@ -434,6 +434,26 @@ config THP_SWAP
> >>  
> >>  	  For selection by architectures with reasonable THP sizes.
> >>  
> >> +config VMA_SWAP_READAHEAD
> >> +	bool "VMA based swap readahead"
> >> +	depends on SWAP
> >> +	default y
> >> +	help
> >> +	  VMA based swap readahead detects page accessing pattern in a
> >> +	  VMA and adjust the swap readahead window for pages in the
> >> +	  VMA accordingly.  It works better for more complex workload
> >> +	  compared with the original physical swap readahead.
> >> +
> >> +	  It can be controlled via the following sysfs interface,
> >> +
> >> +	    /sys/kernel/mm/swap/vma_ra_enabled
> >> +	    /sys/kernel/mm/swap/vma_ra_max_order
> >
> > It might be better to discuss in other thread but if you mention new
> > interface here again, I will discuss it here.
> >
> > We are creating new ABI in here so I want to ask question in here.
> >
> > Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
> > swap readahead knob? Reusing such common/consistent knob would be better
> > than adding new separate konb.
> 
> The problem is that the configuration of VMA based swap readahead is
> global instead of block device specific.  And because it works in
> virtual way, that is, the swap blocks on the different block devices may
> be readahead together.  It's a little hard to use the block device
> specific configuration.

Fair enough. page-cluster from the beginning should have been like that
instead of vma_ra_max_order.

One more questions: Do we need separate vma_ra_enable?

Can't we disable it via echo 0 > /sys/kernel/mm/swap/vma_ra_max_order
like page-cluster?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

Minchan Kim <minchan@kernel.org> writes:

> On Mon, Sep 25, 2017 at 01:54:42PM +0800, Huang, Ying wrote:
>> Hi, Minchan,
>> 
>> Minchan Kim <minchan@kernel.org> writes:
>> 
>> > Hi Huang,
>> >
>> > On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
>> >> From: Huang Ying <ying.huang@intel.com>
>> 
>> [snip]
>> 
>> >> diff --git a/mm/Kconfig b/mm/Kconfig
>> >> index 9c4bdddd80c2..e62c8e2e34ef 100644
>> >> --- a/mm/Kconfig
>> >> +++ b/mm/Kconfig
>> >> @@ -434,6 +434,26 @@ config THP_SWAP
>> >>  
>> >>  	  For selection by architectures with reasonable THP sizes.
>> >>  
>> >> +config VMA_SWAP_READAHEAD
>> >> +	bool "VMA based swap readahead"
>> >> +	depends on SWAP
>> >> +	default y
>> >> +	help
>> >> +	  VMA based swap readahead detects page accessing pattern in a
>> >> +	  VMA and adjust the swap readahead window for pages in the
>> >> +	  VMA accordingly.  It works better for more complex workload
>> >> +	  compared with the original physical swap readahead.
>> >> +
>> >> +	  It can be controlled via the following sysfs interface,
>> >> +
>> >> +	    /sys/kernel/mm/swap/vma_ra_enabled
>> >> +	    /sys/kernel/mm/swap/vma_ra_max_order
>> >
>> > It might be better to discuss in other thread but if you mention new
>> > interface here again, I will discuss it here.
>> >
>> > We are creating new ABI in here so I want to ask question in here.
>> >
>> > Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
>> > swap readahead knob? Reusing such common/consistent knob would be better
>> > than adding new separate konb.
>> 
>> The problem is that the configuration of VMA based swap readahead is
>> global instead of block device specific.  And because it works in
>> virtual way, that is, the swap blocks on the different block devices may
>> be readahead together.  It's a little hard to use the block device
>> specific configuration.
>
> Fair enough. page-cluster from the beginning should have been like that
> instead of vma_ra_max_order.
>
> One more questions: Do we need separate vma_ra_enable?
>
> Can't we disable it via echo 0 > /sys/kernel/mm/swap/vma_ra_max_order
> like page-cluster?

The difference is,

vma_ra_eanble: 0
  => use original physical swap readahead

vma_ra_enable: 1 && vma_ra_max_order: 0
  => use VMA based swap readahead and disable the readahead.

Best Regards,
Huang, Ying

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

Minchan Kim <minchan@kernel.org> writes:

> On Mon, Sep 25, 2017 at 01:54:42PM +0800, Huang, Ying wrote:
>> Hi, Minchan,
>> 
>> Minchan Kim <minchan@kernel.org> writes:
>> 
>> > Hi Huang,
>> >
>> > On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
>> >> From: Huang Ying <ying.huang@intel.com>
>> 
>> [snip]
>> 
>> >> diff --git a/mm/Kconfig b/mm/Kconfig
>> >> index 9c4bdddd80c2..e62c8e2e34ef 100644
>> >> --- a/mm/Kconfig
>> >> +++ b/mm/Kconfig
>> >> @@ -434,6 +434,26 @@ config THP_SWAP
>> >>  
>> >>  	  For selection by architectures with reasonable THP sizes.
>> >>  
>> >> +config VMA_SWAP_READAHEAD
>> >> +	bool "VMA based swap readahead"
>> >> +	depends on SWAP
>> >> +	default y
>> >> +	help
>> >> +	  VMA based swap readahead detects page accessing pattern in a
>> >> +	  VMA and adjust the swap readahead window for pages in the
>> >> +	  VMA accordingly.  It works better for more complex workload
>> >> +	  compared with the original physical swap readahead.
>> >> +
>> >> +	  It can be controlled via the following sysfs interface,
>> >> +
>> >> +	    /sys/kernel/mm/swap/vma_ra_enabled
>> >> +	    /sys/kernel/mm/swap/vma_ra_max_order
>> >
>> > It might be better to discuss in other thread but if you mention new
>> > interface here again, I will discuss it here.
>> >
>> > We are creating new ABI in here so I want to ask question in here.
>> >
>> > Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
>> > swap readahead knob? Reusing such common/consistent knob would be better
>> > than adding new separate konb.
>> 
>> The problem is that the configuration of VMA based swap readahead is
>> global instead of block device specific.  And because it works in
>> virtual way, that is, the swap blocks on the different block devices may
>> be readahead together.  It's a little hard to use the block device
>> specific configuration.
>
> Fair enough. page-cluster from the beginning should have been like that
> instead of vma_ra_max_order.
>
> One more questions: Do we need separate vma_ra_enable?
>
> Can't we disable it via echo 0 > /sys/kernel/mm/swap/vma_ra_max_order
> like page-cluster?

The difference is,

vma_ra_eanble: 0
  => use original physical swap readahead

vma_ra_enable: 1 && vma_ra_max_order: 0
  => use VMA based swap readahead and disable the readahead.

Best Regards,
Huang, Ying

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Mon, Sep 25, 2017 at 02:24:46PM +0800, Huang, Ying wrote:
> Minchan Kim <minchan@kernel.org> writes:
> 
> > On Mon, Sep 25, 2017 at 01:54:42PM +0800, Huang, Ying wrote:
> >> Hi, Minchan,
> >> 
> >> Minchan Kim <minchan@kernel.org> writes:
> >> 
> >> > Hi Huang,
> >> >
> >> > On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
> >> >> From: Huang Ying <ying.huang@intel.com>
> >> 
> >> [snip]
> >> 
> >> >> diff --git a/mm/Kconfig b/mm/Kconfig
> >> >> index 9c4bdddd80c2..e62c8e2e34ef 100644
> >> >> --- a/mm/Kconfig
> >> >> +++ b/mm/Kconfig
> >> >> @@ -434,6 +434,26 @@ config THP_SWAP
> >> >>  
> >> >>  	  For selection by architectures with reasonable THP sizes.
> >> >>  
> >> >> +config VMA_SWAP_READAHEAD
> >> >> +	bool "VMA based swap readahead"
> >> >> +	depends on SWAP
> >> >> +	default y
> >> >> +	help
> >> >> +	  VMA based swap readahead detects page accessing pattern in a
> >> >> +	  VMA and adjust the swap readahead window for pages in the
> >> >> +	  VMA accordingly.  It works better for more complex workload
> >> >> +	  compared with the original physical swap readahead.
> >> >> +
> >> >> +	  It can be controlled via the following sysfs interface,
> >> >> +
> >> >> +	    /sys/kernel/mm/swap/vma_ra_enabled
> >> >> +	    /sys/kernel/mm/swap/vma_ra_max_order
> >> >
> >> > It might be better to discuss in other thread but if you mention new
> >> > interface here again, I will discuss it here.
> >> >
> >> > We are creating new ABI in here so I want to ask question in here.
> >> >
> >> > Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
> >> > swap readahead knob? Reusing such common/consistent knob would be better
> >> > than adding new separate konb.
> >> 
> >> The problem is that the configuration of VMA based swap readahead is
> >> global instead of block device specific.  And because it works in
> >> virtual way, that is, the swap blocks on the different block devices may
> >> be readahead together.  It's a little hard to use the block device
> >> specific configuration.
> >
> > Fair enough. page-cluster from the beginning should have been like that
> > instead of vma_ra_max_order.
> >
> > One more questions: Do we need separate vma_ra_enable?
> >
> > Can't we disable it via echo 0 > /sys/kernel/mm/swap/vma_ra_max_order
> > like page-cluster?
> 
> The difference is,
> 
> vma_ra_eanble: 0
>   => use original physical swap readahead
> 
> vma_ra_enable: 1 && vma_ra_max_order: 0
>   => use VMA based swap readahead and disable the readahead.

I understand now. Thanks!

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Mon, Sep 25, 2017 at 02:24:46PM +0800, Huang, Ying wrote:
> Minchan Kim <minchan@kernel.org> writes:
> 
> > On Mon, Sep 25, 2017 at 01:54:42PM +0800, Huang, Ying wrote:
> >> Hi, Minchan,
> >> 
> >> Minchan Kim <minchan@kernel.org> writes:
> >> 
> >> > Hi Huang,
> >> >
> >> > On Thu, Sep 21, 2017 at 09:33:10AM +0800, Huang, Ying wrote:
> >> >> From: Huang Ying <ying.huang@intel.com>
> >> 
> >> [snip]
> >> 
> >> >> diff --git a/mm/Kconfig b/mm/Kconfig
> >> >> index 9c4bdddd80c2..e62c8e2e34ef 100644
> >> >> --- a/mm/Kconfig
> >> >> +++ b/mm/Kconfig
> >> >> @@ -434,6 +434,26 @@ config THP_SWAP
> >> >>  
> >> >>  	  For selection by architectures with reasonable THP sizes.
> >> >>  
> >> >> +config VMA_SWAP_READAHEAD
> >> >> +	bool "VMA based swap readahead"
> >> >> +	depends on SWAP
> >> >> +	default y
> >> >> +	help
> >> >> +	  VMA based swap readahead detects page accessing pattern in a
> >> >> +	  VMA and adjust the swap readahead window for pages in the
> >> >> +	  VMA accordingly.  It works better for more complex workload
> >> >> +	  compared with the original physical swap readahead.
> >> >> +
> >> >> +	  It can be controlled via the following sysfs interface,
> >> >> +
> >> >> +	    /sys/kernel/mm/swap/vma_ra_enabled
> >> >> +	    /sys/kernel/mm/swap/vma_ra_max_order
> >> >
> >> > It might be better to discuss in other thread but if you mention new
> >> > interface here again, I will discuss it here.
> >> >
> >> > We are creating new ABI in here so I want to ask question in here.
> >> >
> >> > Did you consier to use /sys/block/xxx/queue/read_ahead_kb for the
> >> > swap readahead knob? Reusing such common/consistent knob would be better
> >> > than adding new separate konb.
> >> 
> >> The problem is that the configuration of VMA based swap readahead is
> >> global instead of block device specific.  And because it works in
> >> virtual way, that is, the swap blocks on the different block devices may
> >> be readahead together.  It's a little hard to use the block device
> >> specific configuration.
> >
> > Fair enough. page-cluster from the beginning should have been like that
> > instead of vma_ra_max_order.
> >
> > One more questions: Do we need separate vma_ra_enable?
> >
> > Can't we disable it via echo 0 > /sys/kernel/mm/swap/vma_ra_max_order
> > like page-cluster?
> 
> The difference is,
> 
> vma_ra_eanble: 0
>   => use original physical swap readahead
> 
> vma_ra_enable: 1 && vma_ra_max_order: 0
>   => use VMA based swap readahead and disable the readahead.

I understand now. Thanks!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Thu 21-09-17 09:33:10, Huang, Ying wrote:
> From: Huang Ying <ying.huang@intel.com>
> 
> This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> This is more friendly for tiny kernels.

How (much)?

> And as pointed to by Minchan
> Kim, give people who want to disable the swap readahead an opportunity
> to notice the changes to the swap readahead algorithm and the
> corresponding knobs.

Why would anyone want that?

Please note that adding new config options make the already complicated
config space even more problematic so there should be a good reason to
add one. Please make sure your justification is clear on why this is
worth the future maintenance and configurability burden.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Thu 21-09-17 09:33:10, Huang, Ying wrote:
> From: Huang Ying <ying.huang@intel.com>
> 
> This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> This is more friendly for tiny kernels.

How (much)?

> And as pointed to by Minchan
> Kim, give people who want to disable the swap readahead an opportunity
> to notice the changes to the swap readahead algorithm and the
> corresponding knobs.

Why would anyone want that?

Please note that adding new config options make the already complicated
config space even more problematic so there should be a good reason to
add one. Please make sure your justification is clear on why this is
worth the future maintenance and configurability burden.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

Michal Hocko <mhocko@kernel.org> writes:

> On Thu 21-09-17 09:33:10, Huang, Ying wrote:
>> From: Huang Ying <ying.huang@intel.com>
>> 
>> This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
>> based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
>> This is more friendly for tiny kernels.
>
> How (much)?

OK.  I will measure it.

>> And as pointed to by Minchan
>> Kim, give people who want to disable the swap readahead an opportunity
>> to notice the changes to the swap readahead algorithm and the
>> corresponding knobs.
>
> Why would anyone want that?
>
> Please note that adding new config options make the already complicated
> config space even more problematic so there should be a good reason to
> add one. Please make sure your justification is clear on why this is
> worth the future maintenance and configurability burden.

Hi, Minchan,

Could you give more information on this?

Best Regards,
Huang, Ying

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

Michal Hocko <mhocko@kernel.org> writes:

> On Thu 21-09-17 09:33:10, Huang, Ying wrote:
>> From: Huang Ying <ying.huang@intel.com>
>> 
>> This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
>> based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
>> This is more friendly for tiny kernels.
>
> How (much)?

OK.  I will measure it.

>> And as pointed to by Minchan
>> Kim, give people who want to disable the swap readahead an opportunity
>> to notice the changes to the swap readahead algorithm and the
>> corresponding knobs.
>
> Why would anyone want that?
>
> Please note that adding new config options make the already complicated
> config space even more problematic so there should be a good reason to
> add one. Please make sure your justification is clear on why this is
> worth the future maintenance and configurability burden.

Hi, Minchan,

Could you give more information on this?

Best Regards,
Huang, Ying

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Tue, Sep 26, 2017 at 03:21:29PM +0200, Michal Hocko wrote:
> On Thu 21-09-17 09:33:10, Huang, Ying wrote:
> > From: Huang Ying <ying.huang@intel.com>
> > 
> > This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> > based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> > This is more friendly for tiny kernels.
> 
> How (much)?
> 
> > And as pointed to by Minchan
> > Kim, give people who want to disable the swap readahead an opportunity
> > to notice the changes to the swap readahead algorithm and the
> > corresponding knobs.
> 
> Why would anyone want that?
> 
> Please note that adding new config options make the already complicated
> config space even more problematic so there should be a good reason to
> add one. Please make sure your justification is clear on why this is
> worth the future maintenance and configurability burden.

The problem is users have disabled swap readahead by echo 0 > /proc/sys/
vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
vma_ra_max_order. Because for disabling readahead completely, they should
disable vma_ra_max_order as well as page-cluster from now on.

So, goal of new config to notice new feature to admins so they can be aware
of new konb vma_ra_max_order as well as page-cluster.
I canont think other better idea to preventing such regression.

http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Tue, Sep 26, 2017 at 03:21:29PM +0200, Michal Hocko wrote:
> On Thu 21-09-17 09:33:10, Huang, Ying wrote:
> > From: Huang Ying <ying.huang@intel.com>
> > 
> > This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> > based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> > This is more friendly for tiny kernels.
> 
> How (much)?
> 
> > And as pointed to by Minchan
> > Kim, give people who want to disable the swap readahead an opportunity
> > to notice the changes to the swap readahead algorithm and the
> > corresponding knobs.
> 
> Why would anyone want that?
> 
> Please note that adding new config options make the already complicated
> config space even more problematic so there should be a good reason to
> add one. Please make sure your justification is clear on why this is
> worth the future maintenance and configurability burden.

The problem is users have disabled swap readahead by echo 0 > /proc/sys/
vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
vma_ra_max_order. Because for disabling readahead completely, they should
disable vma_ra_max_order as well as page-cluster from now on.

So, goal of new config to notice new feature to admins so they can be aware
of new konb vma_ra_max_order as well as page-cluster.
I canont think other better idea to preventing such regression.

http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> On Tue, Sep 26, 2017 at 03:21:29PM +0200, Michal Hocko wrote:
> > On Thu 21-09-17 09:33:10, Huang, Ying wrote:
> > > From: Huang Ying <ying.huang@intel.com>
> > > 
> > > This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> > > based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> > > This is more friendly for tiny kernels.
> > 
> > How (much)?
> > 
> > > And as pointed to by Minchan
> > > Kim, give people who want to disable the swap readahead an opportunity
> > > to notice the changes to the swap readahead algorithm and the
> > > corresponding knobs.
> > 
> > Why would anyone want that?
> > 
> > Please note that adding new config options make the already complicated
> > config space even more problematic so there should be a good reason to
> > add one. Please make sure your justification is clear on why this is
> > worth the future maintenance and configurability burden.
> 
> The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> vma_ra_max_order. Because for disabling readahead completely, they should
> disable vma_ra_max_order as well as page-cluster from now on.
> 
> So, goal of new config to notice new feature to admins so they can be aware
> of new konb vma_ra_max_order as well as page-cluster.
> I canont think other better idea to preventing such regression.
> 
> http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E

So, how are you going to configure this when you do not know whether
zram will be used? In other words what should e.g. distribution set this
to?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> On Tue, Sep 26, 2017 at 03:21:29PM +0200, Michal Hocko wrote:
> > On Thu 21-09-17 09:33:10, Huang, Ying wrote:
> > > From: Huang Ying <ying.huang@intel.com>
> > > 
> > > This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> > > based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> > > This is more friendly for tiny kernels.
> > 
> > How (much)?
> > 
> > > And as pointed to by Minchan
> > > Kim, give people who want to disable the swap readahead an opportunity
> > > to notice the changes to the swap readahead algorithm and the
> > > corresponding knobs.
> > 
> > Why would anyone want that?
> > 
> > Please note that adding new config options make the already complicated
> > config space even more problematic so there should be a good reason to
> > add one. Please make sure your justification is clear on why this is
> > worth the future maintenance and configurability burden.
> 
> The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> vma_ra_max_order. Because for disabling readahead completely, they should
> disable vma_ra_max_order as well as page-cluster from now on.
> 
> So, goal of new config to notice new feature to admins so they can be aware
> of new konb vma_ra_max_order as well as page-cluster.
> I canont think other better idea to preventing such regression.
> 
> http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E

So, how are you going to configure this when you do not know whether
zram will be used? In other words what should e.g. distribution set this
to?

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> > On Tue, Sep 26, 2017 at 03:21:29PM +0200, Michal Hocko wrote:
> > > On Thu 21-09-17 09:33:10, Huang, Ying wrote:
> > > > From: Huang Ying <ying.huang@intel.com>
> > > > 
> > > > This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> > > > based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> > > > This is more friendly for tiny kernels.
> > > 
> > > How (much)?
> > > 
> > > > And as pointed to by Minchan
> > > > Kim, give people who want to disable the swap readahead an opportunity
> > > > to notice the changes to the swap readahead algorithm and the
> > > > corresponding knobs.
> > > 
> > > Why would anyone want that?
> > > 
> > > Please note that adding new config options make the already complicated
> > > config space even more problematic so there should be a good reason to
> > > add one. Please make sure your justification is clear on why this is
> > > worth the future maintenance and configurability burden.
> > 
> > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > vma_ra_max_order. Because for disabling readahead completely, they should
> > disable vma_ra_max_order as well as page-cluster from now on.
> > 
> > So, goal of new config to notice new feature to admins so they can be aware
> > of new konb vma_ra_max_order as well as page-cluster.
> > I canont think other better idea to preventing such regression.
> > 
> > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> 
> So, how are you going to configure this when you do not know whether
> zram will be used? In other words what should e.g. distribution set this
> to?

I have no idea. Unfortunately, it depends on them. If they want to use
zram as swap, they should fix the script. Surely, I don't like it.
Instead, I wanted that page-cluster zeroing disables both virtual/pysical
swap readahead not to break current userspace. However, Huang doesn't
liek it.
If you have better idea, please suggest.

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> > On Tue, Sep 26, 2017 at 03:21:29PM +0200, Michal Hocko wrote:
> > > On Thu 21-09-17 09:33:10, Huang, Ying wrote:
> > > > From: Huang Ying <ying.huang@intel.com>
> > > > 
> > > > This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA
> > > > based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif.
> > > > This is more friendly for tiny kernels.
> > > 
> > > How (much)?
> > > 
> > > > And as pointed to by Minchan
> > > > Kim, give people who want to disable the swap readahead an opportunity
> > > > to notice the changes to the swap readahead algorithm and the
> > > > corresponding knobs.
> > > 
> > > Why would anyone want that?
> > > 
> > > Please note that adding new config options make the already complicated
> > > config space even more problematic so there should be a good reason to
> > > add one. Please make sure your justification is clear on why this is
> > > worth the future maintenance and configurability burden.
> > 
> > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > vma_ra_max_order. Because for disabling readahead completely, they should
> > disable vma_ra_max_order as well as page-cluster from now on.
> > 
> > So, goal of new config to notice new feature to admins so they can be aware
> > of new konb vma_ra_max_order as well as page-cluster.
> > I canont think other better idea to preventing such regression.
> > 
> > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> 
> So, how are you going to configure this when you do not know whether
> zram will be used? In other words what should e.g. distribution set this
> to?

I have no idea. Unfortunately, it depends on them. If they want to use
zram as swap, they should fix the script. Surely, I don't like it.
Instead, I wanted that page-cluster zeroing disables both virtual/pysical
swap readahead not to break current userspace. However, Huang doesn't
liek it.
If you have better idea, please suggest.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 17:04:32, Minchan Kim wrote:
> On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> > On Wed 27-09-17 14:04:01, Minchan Kim wrote:
[...]
> > > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > > vma_ra_max_order. Because for disabling readahead completely, they should
> > > disable vma_ra_max_order as well as page-cluster from now on.
> > > 
> > > So, goal of new config to notice new feature to admins so they can be aware
> > > of new konb vma_ra_max_order as well as page-cluster.
> > > I canont think other better idea to preventing such regression.
> > > 
> > > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> > 
> > So, how are you going to configure this when you do not know whether
> > zram will be used? In other words what should e.g. distribution set this
> > to?
> 
> I have no idea. Unfortunately, it depends on them. If they want to use
> zram as swap, they should fix the script. Surely, I don't like it.
> Instead, I wanted that page-cluster zeroing disables both virtual/pysical
> swap readahead not to break current userspace. However, Huang doesn't
> liek it.
> If you have better idea, please suggest.

I understand your frustration but config options are not there to bypass
proper design decisions. Why cannot we unconditionally disable all the
read ahead when zram is enabled?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 17:04:32, Minchan Kim wrote:
> On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> > On Wed 27-09-17 14:04:01, Minchan Kim wrote:
[...]
> > > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > > vma_ra_max_order. Because for disabling readahead completely, they should
> > > disable vma_ra_max_order as well as page-cluster from now on.
> > > 
> > > So, goal of new config to notice new feature to admins so they can be aware
> > > of new konb vma_ra_max_order as well as page-cluster.
> > > I canont think other better idea to preventing such regression.
> > > 
> > > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> > 
> > So, how are you going to configure this when you do not know whether
> > zram will be used? In other words what should e.g. distribution set this
> > to?
> 
> I have no idea. Unfortunately, it depends on them. If they want to use
> zram as swap, they should fix the script. Surely, I don't like it.
> Instead, I wanted that page-cluster zeroing disables both virtual/pysical
> swap readahead not to break current userspace. However, Huang doesn't
> liek it.
> If you have better idea, please suggest.

I understand your frustration but config options are not there to bypass
proper design decisions. Why cannot we unconditionally disable all the
read ahead when zram is enabled?
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Wed, Sep 27, 2017 at 10:35:12AM +0200, Michal Hocko wrote:
> On Wed 27-09-17 17:04:32, Minchan Kim wrote:
> > On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> > > On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> [...]
> > > > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > > > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > > > vma_ra_max_order. Because for disabling readahead completely, they should
> > > > disable vma_ra_max_order as well as page-cluster from now on.
> > > > 
> > > > So, goal of new config to notice new feature to admins so they can be aware
> > > > of new konb vma_ra_max_order as well as page-cluster.
> > > > I canont think other better idea to preventing such regression.
> > > > 
> > > > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> > > 
> > > So, how are you going to configure this when you do not know whether
> > > zram will be used? In other words what should e.g. distribution set this
> > > to?
> > 
> > I have no idea. Unfortunately, it depends on them. If they want to use
> > zram as swap, they should fix the script. Surely, I don't like it.
> > Instead, I wanted that page-cluster zeroing disables both virtual/pysical
> > swap readahead not to break current userspace. However, Huang doesn't
> > liek it.
> > If you have better idea, please suggest.
> 
> I understand your frustration but config options are not there to bypass
> proper design decisions. Why cannot we unconditionally disable all the
> read ahead when zram is enabled?

It's not a zram specific issue. Every users who have disabled swap readahead
via page-cluster will be broken, too.

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Wed, Sep 27, 2017 at 10:35:12AM +0200, Michal Hocko wrote:
> On Wed 27-09-17 17:04:32, Minchan Kim wrote:
> > On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> > > On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> [...]
> > > > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > > > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > > > vma_ra_max_order. Because for disabling readahead completely, they should
> > > > disable vma_ra_max_order as well as page-cluster from now on.
> > > > 
> > > > So, goal of new config to notice new feature to admins so they can be aware
> > > > of new konb vma_ra_max_order as well as page-cluster.
> > > > I canont think other better idea to preventing such regression.
> > > > 
> > > > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> > > 
> > > So, how are you going to configure this when you do not know whether
> > > zram will be used? In other words what should e.g. distribution set this
> > > to?
> > 
> > I have no idea. Unfortunately, it depends on them. If they want to use
> > zram as swap, they should fix the script. Surely, I don't like it.
> > Instead, I wanted that page-cluster zeroing disables both virtual/pysical
> > swap readahead not to break current userspace. However, Huang doesn't
> > liek it.
> > If you have better idea, please suggest.
> 
> I understand your frustration but config options are not there to bypass
> proper design decisions. Why cannot we unconditionally disable all the
> read ahead when zram is enabled?

It's not a zram specific issue. Every users who have disabled swap readahead
via page-cluster will be broken, too.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 22:15:11, Minchan Kim wrote:
> On Wed, Sep 27, 2017 at 10:35:12AM +0200, Michal Hocko wrote:
> > On Wed 27-09-17 17:04:32, Minchan Kim wrote:
> > > On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> > > > On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> > [...]
> > > > > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > > > > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > > > > vma_ra_max_order. Because for disabling readahead completely, they should
> > > > > disable vma_ra_max_order as well as page-cluster from now on.
> > > > > 
> > > > > So, goal of new config to notice new feature to admins so they can be aware
> > > > > of new konb vma_ra_max_order as well as page-cluster.
> > > > > I canont think other better idea to preventing such regression.
> > > > > 
> > > > > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> > > > 
> > > > So, how are you going to configure this when you do not know whether
> > > > zram will be used? In other words what should e.g. distribution set this
> > > > to?
> > > 
> > > I have no idea. Unfortunately, it depends on them. If they want to use
> > > zram as swap, they should fix the script. Surely, I don't like it.
> > > Instead, I wanted that page-cluster zeroing disables both virtual/pysical
> > > swap readahead not to break current userspace. However, Huang doesn't
> > > liek it.
> > > If you have better idea, please suggest.
> > 
> > I understand your frustration but config options are not there to bypass
> > proper design decisions. Why cannot we unconditionally disable all the
> > read ahead when zram is enabled?
> 
> It's not a zram specific issue. Every users who have disabled swap readahead
> via page-cluster will be broken, too.

Do you have any examples outside of zram? Also I do not see why we
simply cannot disable swap readahead when page-cluster is 0?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 22:15:11, Minchan Kim wrote:
> On Wed, Sep 27, 2017 at 10:35:12AM +0200, Michal Hocko wrote:
> > On Wed 27-09-17 17:04:32, Minchan Kim wrote:
> > > On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> > > > On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> > [...]
> > > > > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > > > > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > > > > vma_ra_max_order. Because for disabling readahead completely, they should
> > > > > disable vma_ra_max_order as well as page-cluster from now on.
> > > > > 
> > > > > So, goal of new config to notice new feature to admins so they can be aware
> > > > > of new konb vma_ra_max_order as well as page-cluster.
> > > > > I canont think other better idea to preventing such regression.
> > > > > 
> > > > > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> > > > 
> > > > So, how are you going to configure this when you do not know whether
> > > > zram will be used? In other words what should e.g. distribution set this
> > > > to?
> > > 
> > > I have no idea. Unfortunately, it depends on them. If they want to use
> > > zram as swap, they should fix the script. Surely, I don't like it.
> > > Instead, I wanted that page-cluster zeroing disables both virtual/pysical
> > > swap readahead not to break current userspace. However, Huang doesn't
> > > liek it.
> > > If you have better idea, please suggest.
> > 
> > I understand your frustration but config options are not there to bypass
> > proper design decisions. Why cannot we unconditionally disable all the
> > read ahead when zram is enabled?
> 
> It's not a zram specific issue. Every users who have disabled swap readahead
> via page-cluster will be broken, too.

Do you have any examples outside of zram? Also I do not see why we
simply cannot disable swap readahead when page-cluster is 0?
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
> On Wed 27-09-17 22:15:11, Minchan Kim wrote:
> > On Wed, Sep 27, 2017 at 10:35:12AM +0200, Michal Hocko wrote:
> > > On Wed 27-09-17 17:04:32, Minchan Kim wrote:
> > > > On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> > > > > On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> > > [...]
> > > > > > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > > > > > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > > > > > vma_ra_max_order. Because for disabling readahead completely, they should
> > > > > > disable vma_ra_max_order as well as page-cluster from now on.
> > > > > > 
> > > > > > So, goal of new config to notice new feature to admins so they can be aware
> > > > > > of new konb vma_ra_max_order as well as page-cluster.
> > > > > > I canont think other better idea to preventing such regression.
> > > > > > 
> > > > > > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> > > > > 
> > > > > So, how are you going to configure this when you do not know whether
> > > > > zram will be used? In other words what should e.g. distribution set this
> > > > > to?
> > > > 
> > > > I have no idea. Unfortunately, it depends on them. If they want to use
> > > > zram as swap, they should fix the script. Surely, I don't like it.
> > > > Instead, I wanted that page-cluster zeroing disables both virtual/pysical
> > > > swap readahead not to break current userspace. However, Huang doesn't
> > > > liek it.
> > > > If you have better idea, please suggest.
> > > 
> > > I understand your frustration but config options are not there to bypass
> > > proper design decisions. Why cannot we unconditionally disable all the
> > > read ahead when zram is enabled?
> > 
> > It's not a zram specific issue. Every users who have disabled swap readahead
> > via page-cluster will be broken, too.
> 
> Do you have any examples outside of zram? Also I do not see why we

I'm not a god to know every usecases on earth. It's just knob and
it's have been there for a long time with following semantic:

        Zero disables swap readahead completely.

So, anyuser can use it by their reasons(e.g., small memory system)

I don't want to play with pointless game "Hey, give me an example.
If you couldn't, no worth to keep the semantic" on such long time
simple/clear semantic.


> simply cannot disable swap readahead when page-cluster is 0?

That's was what I want really but Huang want to use two readahead
algorithms in parallel so he wanted to keep two separated disable
knobs.


> -- 
> Michal Hocko
> SUSE Labs

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
> On Wed 27-09-17 22:15:11, Minchan Kim wrote:
> > On Wed, Sep 27, 2017 at 10:35:12AM +0200, Michal Hocko wrote:
> > > On Wed 27-09-17 17:04:32, Minchan Kim wrote:
> > > > On Wed, Sep 27, 2017 at 09:48:35AM +0200, Michal Hocko wrote:
> > > > > On Wed 27-09-17 14:04:01, Minchan Kim wrote:
> > > [...]
> > > > > > The problem is users have disabled swap readahead by echo 0 > /proc/sys/
> > > > > > vm/page-cluster are regressed by this new interface /sys/kernel/mm/swap/
> > > > > > vma_ra_max_order. Because for disabling readahead completely, they should
> > > > > > disable vma_ra_max_order as well as page-cluster from now on.
> > > > > > 
> > > > > > So, goal of new config to notice new feature to admins so they can be aware
> > > > > > of new konb vma_ra_max_order as well as page-cluster.
> > > > > > I canont think other better idea to preventing such regression.
> > > > > > 
> > > > > > http://lkml.kernel.org/r/%3C20170913014019.GB29422@bbox%3E
> > > > > 
> > > > > So, how are you going to configure this when you do not know whether
> > > > > zram will be used? In other words what should e.g. distribution set this
> > > > > to?
> > > > 
> > > > I have no idea. Unfortunately, it depends on them. If they want to use
> > > > zram as swap, they should fix the script. Surely, I don't like it.
> > > > Instead, I wanted that page-cluster zeroing disables both virtual/pysical
> > > > swap readahead not to break current userspace. However, Huang doesn't
> > > > liek it.
> > > > If you have better idea, please suggest.
> > > 
> > > I understand your frustration but config options are not there to bypass
> > > proper design decisions. Why cannot we unconditionally disable all the
> > > read ahead when zram is enabled?
> > 
> > It's not a zram specific issue. Every users who have disabled swap readahead
> > via page-cluster will be broken, too.
> 
> Do you have any examples outside of zram? Also I do not see why we

I'm not a god to know every usecases on earth. It's just knob and
it's have been there for a long time with following semantic:

        Zero disables swap readahead completely.

So, anyuser can use it by their reasons(e.g., small memory system)

I don't want to play with pointless game "Hey, give me an example.
If you couldn't, no worth to keep the semantic" on such long time
simple/clear semantic.


> simply cannot disable swap readahead when page-cluster is 0?

That's was what I want really but Huang want to use two readahead
algorithms in parallel so he wanted to keep two separated disable
knobs.


> -- 
> Michal Hocko
> SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 22:41:17, Minchan Kim wrote:
> On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
[...]
> > simply cannot disable swap readahead when page-cluster is 0?
> 
> That's was what I want really but Huang want to use two readahead
> algorithms in parallel so he wanted to keep two separated disable
> knobs.

If it breaks existing and documented behavior then it is a clear
regression and it should be fixed. I do not see why this should be
disputable at all.

Working around an issue with a config option sounds like the wrong way
to go because those who cannot do that unconditionally would still see a
regression.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 22:41:17, Minchan Kim wrote:
> On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
[...]
> > simply cannot disable swap readahead when page-cluster is 0?
> 
> That's was what I want really but Huang want to use two readahead
> algorithms in parallel so he wanted to keep two separated disable
> knobs.

If it breaks existing and documented behavior then it is a clear
regression and it should be fixed. I do not see why this should be
disputable at all.

Working around an issue with a config option sounds like the wrong way
to go because those who cannot do that unconditionally would still see a
regression.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Wed, Sep 27, 2017 at 03:50:34PM +0200, Michal Hocko wrote:
> On Wed 27-09-17 22:41:17, Minchan Kim wrote:
> > On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
> [...]
> > > simply cannot disable swap readahead when page-cluster is 0?
> > 
> > That's was what I want really but Huang want to use two readahead
> > algorithms in parallel so he wanted to keep two separated disable
> > knobs.
> 
> If it breaks existing and documented behavior then it is a clear
> regression and it should be fixed. I do not see why this should be
> disputable at all.

Indeed but Huang doesn't think so. He has thought it's not a regression.
Frankly speaking, I'm really bored of discussing with it.
https://marc.info/?l=linux-mm&m=150526413319763&w=2

So I passed the decision to Andrew.
http://lkml.kernel.org/r/<20170913014019.GB29422@bbox>

The config option idea is compromise approach although I don't like it
and still believe it's simple clear *regression* so 0 page-cluster
should keep the swap readahead disabled.

> 
> Working around an issue with a config option sounds like the wrong way
> to go because those who cannot do that unconditionally would still see a
> regression.

I absolutely agree but as I said, the discussion was not productive
even though I did best effort to persuade. That's all for my side as
contributor/reviewer. Decision is up to maintainer. ;-)

Thanks for the opinion, Michal.

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Minchan Kim]

On Wed, Sep 27, 2017 at 03:50:34PM +0200, Michal Hocko wrote:
> On Wed 27-09-17 22:41:17, Minchan Kim wrote:
> > On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
> [...]
> > > simply cannot disable swap readahead when page-cluster is 0?
> > 
> > That's was what I want really but Huang want to use two readahead
> > algorithms in parallel so he wanted to keep two separated disable
> > knobs.
> 
> If it breaks existing and documented behavior then it is a clear
> regression and it should be fixed. I do not see why this should be
> disputable at all.

Indeed but Huang doesn't think so. He has thought it's not a regression.
Frankly speaking, I'm really bored of discussing with it.
https://marc.info/?l=linux-mm&m=150526413319763&w=2

So I passed the decision to Andrew.
http://lkml.kernel.org/r/<20170913014019.GB29422@bbox>

The config option idea is compromise approach although I don't like it
and still believe it's simple clear *regression* so 0 page-cluster
should keep the swap readahead disabled.

> 
> Working around an issue with a config option sounds like the wrong way
> to go because those who cannot do that unconditionally would still see a
> regression.

I absolutely agree but as I said, the discussion was not productive
even though I did best effort to persuade. That's all for my side as
contributor/reviewer. Decision is up to maintainer. ;-)

Thanks for the opinion, Michal.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 23:10:08, Minchan Kim wrote:
> On Wed, Sep 27, 2017 at 03:50:34PM +0200, Michal Hocko wrote:
> > On Wed 27-09-17 22:41:17, Minchan Kim wrote:
> > > On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
> > [...]
> > > > simply cannot disable swap readahead when page-cluster is 0?
> > > 
> > > That's was what I want really but Huang want to use two readahead
> > > algorithms in parallel so he wanted to keep two separated disable
> > > knobs.
> > 
> > If it breaks existing and documented behavior then it is a clear
> > regression and it should be fixed. I do not see why this should be
> > disputable at all.
> 
> Indeed but Huang doesn't think so. He has thought it's not a regression.
> Frankly speaking, I'm really bored of discussing with it.
> https://marc.info/?l=linux-mm&m=150526413319763&w=2

Then send a patch explaining why you consider this a regression with
some numbers backing it and I will happily ack it.

> So I passed the decision to Andrew.
> http://lkml.kernel.org/r/<20170913014019.GB29422@bbox>
> 
> The config option idea is compromise approach although I don't like it
> and still believe it's simple clear *regression* so 0 page-cluster
> should keep the swap readahead disabled.

It is not a compromise. The regression is still there for many users
potentially (just consider zram distribution kernel users...).
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Wed 27-09-17 23:10:08, Minchan Kim wrote:
> On Wed, Sep 27, 2017 at 03:50:34PM +0200, Michal Hocko wrote:
> > On Wed 27-09-17 22:41:17, Minchan Kim wrote:
> > > On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
> > [...]
> > > > simply cannot disable swap readahead when page-cluster is 0?
> > > 
> > > That's was what I want really but Huang want to use two readahead
> > > algorithms in parallel so he wanted to keep two separated disable
> > > knobs.
> > 
> > If it breaks existing and documented behavior then it is a clear
> > regression and it should be fixed. I do not see why this should be
> > disputable at all.
> 
> Indeed but Huang doesn't think so. He has thought it's not a regression.
> Frankly speaking, I'm really bored of discussing with it.
> https://marc.info/?l=linux-mm&m=150526413319763&w=2

Then send a patch explaining why you consider this a regression with
some numbers backing it and I will happily ack it.

> So I passed the decision to Andrew.
> http://lkml.kernel.org/r/<20170913014019.GB29422@bbox>
> 
> The config option idea is compromise approach although I don't like it
> and still believe it's simple clear *regression* so 0 page-cluster
> should keep the swap readahead disabled.

It is not a compromise. The regression is still there for many users
potentially (just consider zram distribution kernel users...).
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

Hi, Michal,

Michal Hocko <mhocko@kernel.org> writes:

> On Wed 27-09-17 23:10:08, Minchan Kim wrote:
>> On Wed, Sep 27, 2017 at 03:50:34PM +0200, Michal Hocko wrote:
>> > On Wed 27-09-17 22:41:17, Minchan Kim wrote:
>> > > On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
>> > [...]
>> > > > simply cannot disable swap readahead when page-cluster is 0?
>> > > 
>> > > That's was what I want really but Huang want to use two readahead
>> > > algorithms in parallel so he wanted to keep two separated disable
>> > > knobs.
>> > 
>> > If it breaks existing and documented behavior then it is a clear
>> > regression and it should be fixed. I do not see why this should be
>> > disputable at all.
>> 
>> Indeed but Huang doesn't think so. He has thought it's not a regression.
>> Frankly speaking, I'm really bored of discussing with it.
>> https://marc.info/?l=linux-mm&m=150526413319763&w=2
>
> Then send a patch explaining why you consider this a regression with
> some numbers backing it and I will happily ack it.

I still think there may be a performance regression for some users
because of the change of the algorithm and the knobs, and the
performance regression can be resolved via setting the new knob.  But I
don't think there will be a functionality regression.  Do you agree?

Best Regards,
Huang, Ying

>> So I passed the decision to Andrew.
>> http://lkml.kernel.org/r/<20170913014019.GB29422@bbox>
>> 
>> The config option idea is compromise approach although I don't like it
>> and still believe it's simple clear *regression* so 0 page-cluster
>> should keep the swap readahead disabled.
>
> It is not a compromise. The regression is still there for many users
> potentially (just consider zram distribution kernel users...).

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Huang, Ying]

Hi, Michal,

Michal Hocko <mhocko@kernel.org> writes:

> On Wed 27-09-17 23:10:08, Minchan Kim wrote:
>> On Wed, Sep 27, 2017 at 03:50:34PM +0200, Michal Hocko wrote:
>> > On Wed 27-09-17 22:41:17, Minchan Kim wrote:
>> > > On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
>> > [...]
>> > > > simply cannot disable swap readahead when page-cluster is 0?
>> > > 
>> > > That's was what I want really but Huang want to use two readahead
>> > > algorithms in parallel so he wanted to keep two separated disable
>> > > knobs.
>> > 
>> > If it breaks existing and documented behavior then it is a clear
>> > regression and it should be fixed. I do not see why this should be
>> > disputable at all.
>> 
>> Indeed but Huang doesn't think so. He has thought it's not a regression.
>> Frankly speaking, I'm really bored of discussing with it.
>> https://marc.info/?l=linux-mm&m=150526413319763&w=2
>
> Then send a patch explaining why you consider this a regression with
> some numbers backing it and I will happily ack it.

I still think there may be a performance regression for some users
because of the change of the algorithm and the knobs, and the
performance regression can be resolved via setting the new knob.  But I
don't think there will be a functionality regression.  Do you agree?

Best Regards,
Huang, Ying

>> So I passed the decision to Andrew.
>> http://lkml.kernel.org/r/<20170913014019.GB29422@bbox>
>> 
>> The config option idea is compromise approach although I don't like it
>> and still believe it's simple clear *regression* so 0 page-cluster
>> should keep the swap readahead disabled.
>
> It is not a compromise. The regression is still there for many users
> potentially (just consider zram distribution kernel users...).

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Thu 28-09-17 09:02:20, Huang, Ying wrote:
> Hi, Michal,
> 
> Michal Hocko <mhocko@kernel.org> writes:
> 
> > On Wed 27-09-17 23:10:08, Minchan Kim wrote:
> >> On Wed, Sep 27, 2017 at 03:50:34PM +0200, Michal Hocko wrote:
> >> > On Wed 27-09-17 22:41:17, Minchan Kim wrote:
> >> > > On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
> >> > [...]
> >> > > > simply cannot disable swap readahead when page-cluster is 0?
> >> > > 
> >> > > That's was what I want really but Huang want to use two readahead
> >> > > algorithms in parallel so he wanted to keep two separated disable
> >> > > knobs.
> >> > 
> >> > If it breaks existing and documented behavior then it is a clear
> >> > regression and it should be fixed. I do not see why this should be
> >> > disputable at all.
> >> 
> >> Indeed but Huang doesn't think so. He has thought it's not a regression.
> >> Frankly speaking, I'm really bored of discussing with it.
> >> https://marc.info/?l=linux-mm&m=150526413319763&w=2
> >
> > Then send a patch explaining why you consider this a regression with
> > some numbers backing it and I will happily ack it.
> 
> I still think there may be a performance regression for some users
> because of the change of the algorithm and the knobs, and the
> performance regression can be resolved via setting the new knob.  But I
> don't think there will be a functionality regression.  Do you agree?

I am not sure I understand. One thing is clear though. Your change has
introduced a regression as described by Minchan. And that has to be
resolved no matter what. You cannot expect users will tweak the system
to resolve it or configure their systems in a specific way.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Michal Hocko]

On Thu 28-09-17 09:02:20, Huang, Ying wrote:
> Hi, Michal,
> 
> Michal Hocko <mhocko@kernel.org> writes:
> 
> > On Wed 27-09-17 23:10:08, Minchan Kim wrote:
> >> On Wed, Sep 27, 2017 at 03:50:34PM +0200, Michal Hocko wrote:
> >> > On Wed 27-09-17 22:41:17, Minchan Kim wrote:
> >> > > On Wed, Sep 27, 2017 at 03:22:41PM +0200, Michal Hocko wrote:
> >> > [...]
> >> > > > simply cannot disable swap readahead when page-cluster is 0?
> >> > > 
> >> > > That's was what I want really but Huang want to use two readahead
> >> > > algorithms in parallel so he wanted to keep two separated disable
> >> > > knobs.
> >> > 
> >> > If it breaks existing and documented behavior then it is a clear
> >> > regression and it should be fixed. I do not see why this should be
> >> > disputable at all.
> >> 
> >> Indeed but Huang doesn't think so. He has thought it's not a regression.
> >> Frankly speaking, I'm really bored of discussing with it.
> >> https://marc.info/?l=linux-mm&m=150526413319763&w=2
> >
> > Then send a patch explaining why you consider this a regression with
> > some numbers backing it and I will happily ack it.
> 
> I still think there may be a performance regression for some users
> because of the change of the algorithm and the knobs, and the
> performance regression can be resolved via setting the new knob.  But I
> don't think there will be a functionality regression.  Do you agree?

I am not sure I understand. One thing is clear though. Your change has
introduced a regression as described by Minchan. And that has to be
resolved no matter what. You cannot expect users will tweak the system
to resolve it or configure their systems in a specific way.

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Dave Hansen]

On 09/27/2017 06:02 PM, Huang, Ying wrote:
> I still think there may be a performance regression for some users
> because of the change of the algorithm and the knobs, and the
> performance regression can be resolved via setting the new knob.  But I
> don't think there will be a functionality regression.  Do you agree?

A performance regression is a regression.  I don't understand why we are
splitting hairs as to what kind of regression it is.

Are you only willing to fix it if it's a functional regression?

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Dave Hansen]

On 09/27/2017 06:02 PM, Huang, Ying wrote:
> I still think there may be a performance regression for some users
> because of the change of the algorithm and the knobs, and the
> performance regression can be resolved via setting the new knob.  But I
> don't think there will be a functionality regression.  Do you agree?

A performance regression is a regression.  I don't understand why we are
splitting hairs as to what kind of regression it is.

Are you only willing to fix it if it's a functional regression?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Andrew Morton]

On Mon, 2 Oct 2017 08:45:40 -0700 Dave Hansen <dave.hansen@intel.com> wrote:

> On 09/27/2017 06:02 PM, Huang, Ying wrote:
> > I still think there may be a performance regression for some users
> > because of the change of the algorithm and the knobs, and the
> > performance regression can be resolved via setting the new knob.  But I
> > don't think there will be a functionality regression.  Do you agree?
> 
> A performance regression is a regression.  I don't understand why we are
> splitting hairs as to what kind of regression it is.
> 

Yes.

Ying, please find us a way of avoiding any disruption to existing
system setups.  One which doesn't require that the operator perform a
configuration change to restore prior behaviour/performance.  And
please let's get this done well in advance of the 4.14 release.

Thanks.

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[Andrew Morton]

On Mon, 2 Oct 2017 08:45:40 -0700 Dave Hansen <dave.hansen@intel.com> wrote:

> On 09/27/2017 06:02 PM, Huang, Ying wrote:
> > I still think there may be a performance regression for some users
> > because of the change of the algorithm and the knobs, and the
> > performance regression can be resolved via setting the new knob.  But I
> > don't think there will be a functionality regression.  Do you agree?
> 
> A performance regression is a regression.  I don't understand why we are
> splitting hairs as to what kind of regression it is.
> 

Yes.

Ying, please find us a way of avoiding any disruption to existing
system setups.  One which doesn't require that the operator perform a
configuration change to restore prior behaviour/performance.  And
please let's get this done well in advance of the 4.14 release.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[huang ying]

On Tue, Oct 3, 2017 at 5:49 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 2 Oct 2017 08:45:40 -0700 Dave Hansen <dave.hansen@intel.com> wrote:
>
>> On 09/27/2017 06:02 PM, Huang, Ying wrote:
>> > I still think there may be a performance regression for some users
>> > because of the change of the algorithm and the knobs, and the
>> > performance regression can be resolved via setting the new knob.  But I
>> > don't think there will be a functionality regression.  Do you agree?
>>
>> A performance regression is a regression.  I don't understand why we are
>> splitting hairs as to what kind of regression it is.
>>
>
> Yes.
>
> Ying, please find us a way of avoiding any disruption to existing
> system setups.  One which doesn't require that the operator perform a
> configuration change to restore prior behaviour/performance.

Sorry for late.  I am in holiday recently.

OK.  For me, I think the most clean way is to use page_cluster to
control both the virtual and physical swap readahead.  If you are OK
with that, I will prepare the patch.

> And please let's get this done well in advance of the 4.14 release.

Sure.

Best Regards,
Huang, Ying

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

[huang ying]

On Tue, Oct 3, 2017 at 5:49 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 2 Oct 2017 08:45:40 -0700 Dave Hansen <dave.hansen@intel.com> wrote:
>
>> On 09/27/2017 06:02 PM, Huang, Ying wrote:
>> > I still think there may be a performance regression for some users
>> > because of the change of the algorithm and the knobs, and the
>> > performance regression can be resolved via setting the new knob.  But I
>> > don't think there will be a functionality regression.  Do you agree?
>>
>> A performance regression is a regression.  I don't understand why we are
>> splitting hairs as to what kind of regression it is.
>>
>
> Yes.
>
> Ying, please find us a way of avoiding any disruption to existing
> system setups.  One which doesn't require that the operator perform a
> configuration change to restore prior behaviour/performance.

Sorry for late.  I am in holiday recently.

OK.  For me, I think the most clean way is to use page_cluster to
control both the virtual and physical swap readahead.  If you are OK
with that, I will prepare the patch.

> And please let's get this done well in advance of the 4.14 release.

Sure.

Best Regards,
Huang, Ying

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>