LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH 1/1] sysctl: change watermark_scale_factor max limit to 30%
@ 2021-11-24 19:36 Suren Baghdasaryan
  2021-11-24 21:37 ` Johannes Weiner
  0 siblings, 1 reply; 3+ messages in thread
From: Suren Baghdasaryan @ 2021-11-24 19:36 UTC (permalink / raw)
  To: akpm
  Cc: mhocko, hannes, mcgrof, keescook, yzaikin, dave.hansen, vbabka,
	mgorman, corbet, yi.zhang, xi.fengfei, rppt, linux-doc,
	linux-kernel, linux-fsdevel, kernel-team, surenb

For embedded systems with low total memory, having to run applications
with relatively large memory requirements, 10% max limitation for
watermark_scale_factor poses an issue of triggering direct reclaim
every time such application is started. This results in slow application
startup times and bad end-user experience.
By increasing watermark_scale_factor max limit we allow vendors more
flexibility to choose the right level of kswapd aggressiveness for
their device and workload requirements.

Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
 Documentation/admin-guide/sysctl/vm.rst | 2 +-
 kernel/sysctl.c                         | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index 5e795202111f..f4804ce37c58 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -948,7 +948,7 @@ how much memory needs to be free before kswapd goes back to sleep.
 
 The unit is in fractions of 10,000. The default value of 10 means the
 distances between watermarks are 0.1% of the available memory in the
-node/system. The maximum value is 1000, or 10% of memory.
+node/system. The maximum value is 3000, or 30% of memory.
 
 A high rate of threads entering direct reclaim (allocstall) or kswapd
 going to sleep prematurely (kswapd_low_wmark_hit_quickly) can indicate
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 083be6af29d7..2ab4edb6e450 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -122,6 +122,7 @@ static unsigned long long_max = LONG_MAX;
 static int one_hundred = 100;
 static int two_hundred = 200;
 static int one_thousand = 1000;
+static int three_thousand = 3000;
 #ifdef CONFIG_PRINTK
 static int ten_thousand = 10000;
 #endif
@@ -2959,7 +2960,7 @@ static struct ctl_table vm_table[] = {
 		.mode		= 0644,
 		.proc_handler	= watermark_scale_factor_sysctl_handler,
 		.extra1		= SYSCTL_ONE,
-		.extra2		= &one_thousand,
+		.extra2		= &three_thousand,
 	},
 	{
 		.procname	= "percpu_pagelist_high_fraction",
-- 
2.34.0.rc2.393.gf8c9666880-goog


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/1] sysctl: change watermark_scale_factor max limit to 30%
  2021-11-24 19:36 [PATCH 1/1] sysctl: change watermark_scale_factor max limit to 30% Suren Baghdasaryan
@ 2021-11-24 21:37 ` Johannes Weiner
  2021-11-24 22:04   ` Suren Baghdasaryan
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Weiner @ 2021-11-24 21:37 UTC (permalink / raw)
  To: Suren Baghdasaryan
  Cc: akpm, mhocko, mcgrof, keescook, yzaikin, dave.hansen, vbabka,
	mgorman, corbet, yi.zhang, xi.fengfei, rppt, linux-doc,
	linux-kernel, linux-fsdevel, kernel-team

On Wed, Nov 24, 2021 at 11:36:04AM -0800, Suren Baghdasaryan wrote:
> For embedded systems with low total memory, having to run applications
> with relatively large memory requirements, 10% max limitation for
> watermark_scale_factor poses an issue of triggering direct reclaim
> every time such application is started. This results in slow application
> startup times and bad end-user experience.
> By increasing watermark_scale_factor max limit we allow vendors more
> flexibility to choose the right level of kswapd aggressiveness for
> their device and workload requirements.
> 
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

No objection from me as this limit was always totally arbitrary. But I
have to say I'm a bit surprised: The current maximum setting will wake
kswapd when free memory drops below 10% and have it reclaim until
20%. This seems like quite a lot? Are there applications that really
want kswapd to wake at 30% and target 60% of memory free?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/1] sysctl: change watermark_scale_factor max limit to 30%
  2021-11-24 21:37 ` Johannes Weiner
@ 2021-11-24 22:04   ` Suren Baghdasaryan
  0 siblings, 0 replies; 3+ messages in thread
From: Suren Baghdasaryan @ 2021-11-24 22:04 UTC (permalink / raw)
  To: Johannes Weiner
  Cc: akpm, mhocko, mcgrof, keescook, yzaikin, dave.hansen, vbabka,
	mgorman, corbet, yi.zhang, xi.fengfei, rppt, linux-doc,
	linux-kernel, linux-fsdevel, kernel-team

On Wed, Nov 24, 2021 at 1:37 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Wed, Nov 24, 2021 at 11:36:04AM -0800, Suren Baghdasaryan wrote:
> > For embedded systems with low total memory, having to run applications
> > with relatively large memory requirements, 10% max limitation for
> > watermark_scale_factor poses an issue of triggering direct reclaim
> > every time such application is started. This results in slow application
> > startup times and bad end-user experience.
> > By increasing watermark_scale_factor max limit we allow vendors more
> > flexibility to choose the right level of kswapd aggressiveness for
> > their device and workload requirements.
> >
> > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Thanks!

>
> No objection from me as this limit was always totally arbitrary. But I
> have to say I'm a bit surprised: The current maximum setting will wake
> kswapd when free memory drops below 10% and have it reclaim until
> 20%. This seems like quite a lot? Are there applications that really
> want kswapd to wake at 30% and target 60% of memory free?

The example I was given by a vendor was Camera application requiring
0.25G on 1GB device. Camera apps are notoriously memory hungry on
Android and on low-memory devices it can require more than 20% of
total memory to run.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-11-24 22:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-24 19:36 [PATCH 1/1] sysctl: change watermark_scale_factor max limit to 30% Suren Baghdasaryan
2021-11-24 21:37 ` Johannes Weiner
2021-11-24 22:04   ` Suren Baghdasaryan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).