[PATCH] mm/madvise: break reclaim when lock race

[PATCH] mm/madvise: break reclaim when lock race

[xf2017140389]

From: xiaofeng <xiaofeng5@xiaomi.com>

When the process_madvise() system call is being used, it takes mmap_lock and blocks the application from allocating memory, leading to unreasonable delays. This patchset aims to fix it.

Signed-off-by: xiaofeng <xiaofeng5@xiaomi.com>
---
 mm/madvise.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/madvise.c b/mm/madvise.c
index 8c927202bbe6..8f1e325873e0 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -322,6 +322,9 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	if (fatal_signal_pending(current))
 		return -EINTR;
 
+	if (mmap_lock_is_contended(mm))
+		return -EINTR;
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	if (pmd_trans_huge(*pmd)) {
 		pmd_t orig_pmd;
-- 
2.17.1

Re: [PATCH] mm/madvise: break reclaim when lock race

[Suren Baghdasaryan]

On Mon, Dec 6, 2021 at 7:22 PM <xf2017140389@gmail.com> wrote:
>
> From: xiaofeng <xiaofeng5@xiaomi.com>
>
> When the process_madvise() system call is being used, it takes mmap_lock and blocks the application from allocating memory, leading to unreasonable delays. This patchset aims to fix it.

Please use checkpatch.pl script before posting (see this blog for
example: http://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/).

Could you please describe your usecase a bit more? Which MADV is being
used specifically (MADV_COLD or MADV_PAGEOUT)?
CC'ing Minchan as he might be interested in learning more about this.

>
> Signed-off-by: xiaofeng <xiaofeng5@xiaomi.com>
> ---
>  mm/madvise.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 8c927202bbe6..8f1e325873e0 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -322,6 +322,9 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>         if (fatal_signal_pending(current))
>                 return -EINTR;
>
> +       if (mmap_lock_is_contended(mm))
> +               return -EINTR;
> +
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>         if (pmd_trans_huge(*pmd)) {
>                 pmd_t orig_pmd;
> --
> 2.17.1
>

Re: [PATCH] mm/madvise: break reclaim when lock race

[Matthew Wilcox]

On Tue, Dec 07, 2021 at 11:22:02AM +0800, xf2017140389@gmail.com wrote:
> From: xiaofeng <xiaofeng5@xiaomi.com>
> 
> When the process_madvise() system call is being used, it takes mmap_lock and blocks the application from allocating memory, leading to unreasonable delays. This patchset aims to fix it.

This means that any page fault will cause madvise() to fail.  NACK.

[PATCH] mm/madvise: break reclaim when lock race

[xf2017140389]

From: xiaofeng <xiaofeng5@xiaomi.com>

In Android phones, the recycling thread is likely to hold the mmap_lock to reclaim the memory of the application When the top-App is switched to the background. Once the user switches the application to the top during the recycling process, there is a high possibility that the memory will be allocated due to the inability to obtain the lock, which may cause lag or other problem.

Signed-off-by: xiaofeng <xiaofeng5@xiaomi.com>
---
 mm/madvise.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/madvise.c b/mm/madvise.c
index 8c927202bbe6..8f1e325873e0 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -322,6 +322,9 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	if (fatal_signal_pending(current))
 		return -EINTR;
 
+	if (mmap_lock_is_contended(mm))
+		return -EINTR;
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	if (pmd_trans_huge(*pmd)) {
 		pmd_t orig_pmd;
-- 
2.17.1