LinuxLists.cc - [PATCH 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink

2015-07-03 13:33:20

Subject: [PATCH 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory feature

2015-07-03 17:22:07

Subject: Re: [PATCH 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory feature

On 03.07.2015 15:20, Pintu Kumar wrote:
> This patch provides 2 things:
> 1. Add new control called shrink_memory in /proc/sys/vm/.
> This control can be used to aggressively reclaim memory system-wide
> in one shot from the user space. A value of 1 will instruct the
> kernel to reclaim as much as totalram_pages in the system.
> Example: echo 1 > /proc/sys/vm/shrink_memory
>
> 2. Enable shrink_all_memory API in kernel with new CONFIG_SHRINK_MEMORY.
> Currently, shrink_all_memory function is used only during hibernation.
> With the new config we can make use of this API for non-hibernation case
> also without disturbing the hibernation case.
>
> The detailed paper was presented in Embedded Linux Conference, Mar-2015
> http://events.linuxfoundation.org/sites/events/files/slides/
> %5BELC-2015%5D-System-wide-Memory-Defragmenter.pdf
>
> Scenarios were this can be used and helpful are:
> 1) Can be invoked just after system boot-up is finished.
> 2) Can be invoked just before entering entire system suspend.
> 3) Can be invoked from kernel when order-4 pages starts failing.
> 4) Can be helpful to completely avoid or delay the kerenl OOM condition.
> 5) Can be developed as a system-tool to quickly defragment entire system
> from user space, without the need to kill any application.
>
> Signed-off-by: Pintu Kumar <[email protected]>
> ---
> Documentation/sysctl/vm.txt | 16 ++++++++++++++++
> include/linux/swap.h | 7 +++++++
> kernel/sysctl.c | 9 +++++++++
> mm/Kconfig | 8 ++++++++
> mm/vmscan.c | 23 +++++++++++++++++++++--
> 5 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> index 9832ec5..a959ad1 100644
> --- a/Documentation/sysctl/vm.txt
> +++ b/Documentation/sysctl/vm.txt
> @@ -54,6 +54,7 @@ Currently, these files are in /proc/sys/vm:
> - page-cluster
> - panic_on_oom
> - percpu_pagelist_fraction
> +- shrink_memory
> - stat_interval
> - swappiness
> - user_reserve_kbytes
> @@ -718,6 +719,21 @@ sysctl, it will revert to this default behavior.
>
> ==============================================================
>
> +shrink_memory
> +
> +This control is available only when CONFIG_SHRINK_MEMORY is set. This control
> +can be used to aggressively reclaim memory system-wide in one shot. A value of
> +1 will instruct the kernel to reclaim as much as totalram_pages in the system.
> +For example, to reclaim all memory system-wide we can do:
> +# echo 1 > /proc/sys/vm/shrink_memory

The API should be as restrictive as possible to allow for extensibility.

You describe "1" as the only used value. So, please add here:

"If any other value than 1 is written to shrink_memory an error
EINVAL occurs."

> +
> +For more information about this control, please visit the following
> +presentation in embedded linux conference, 2015.
> +http://events.linuxfoundation.org/sites/events/files/slides/
> +%5BELC-2015%5D-System-wide-Memory-Defragmenter.pdf
> +
> +==============================================================
> +
> stat_interval
>
> The time interval between which vm statistics are updated. The default
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 9a7adfb..6505b0b 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -333,6 +333,13 @@ extern int vm_swappiness;
> extern int remove_mapping(struct address_space *mapping, struct page *page);
> extern unsigned long vm_total_pages;
>
> +#ifdef CONFIG_SHRINK_MEMORY
> +extern int sysctl_shrink_memory;
> +extern int sysctl_shrinkmem_handler(struct ctl_table *table, int write,
> + void __user *buffer, size_t *length, loff_t *ppos);
> +#endif
> +
> +
> #ifdef CONFIG_NUMA
> extern int zone_reclaim_mode;
> extern int sysctl_min_unmapped_ratio;
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index c566b56..2895099 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1351,6 +1351,15 @@ static struct ctl_table vm_table[] = {
> },
>
> #endif /* CONFIG_COMPACTION */
> +#ifdef CONFIG_SHRINK_MEMORY
> + {
> + .procname = "shrink_memory",
> + .data = &sysctl_shrink_memory,
> + .maxlen = sizeof(int),
> + .mode = 0200,
> + .proc_handler = sysctl_shrinkmem_handler,

Supply the value limits.

int min_shrink_memory = 1;
int max_shrink_memory = 1;

.extra1 = &min_shrink_memory,
.extra2 = &max_shrink_memory,

> + },
> +#endif
> {
> .procname = "min_free_kbytes",
> .data = &min_free_kbytes,
> diff --git a/mm/Kconfig b/mm/Kconfig
> index b3a60ee..8e04bd9 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -657,3 +657,11 @@ config DEFERRED_STRUCT_PAGE_INIT
> when kswapd starts. This has a potential performance impact on
> processes running early in the lifetime of the systemm until kswapd
> finishes the initialisation.
> +
> +config SHRINK_MEMORY
> + bool "Allow for system-wide shrinking of memory"
> + default n
> + depends on MMU
> + help
> + It enables support for system-wide memory reclaim in one shot using
> + echo 1 > /proc/sys/vm/shrink_memory.
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c8d8282..837b88d 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3557,7 +3557,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx)
> wake_up_interruptible(&pgdat->kswapd_wait);
> }
>
> -#ifdef CONFIG_HIBERNATION
> +#if defined CONFIG_HIBERNATION || CONFIG_SHRINK_MEMORY
> /*
> * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of
> * freed pages.
> @@ -3571,12 +3571,17 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim)
> struct reclaim_state reclaim_state;
> struct scan_control sc = {
> .nr_to_reclaim = nr_to_reclaim,
> +#ifdef CONFIG_SHRINK_MEMORY
> + .gfp_mask = (GFP_HIGHUSER_MOVABLE | GFP_RECLAIM_MASK),
> + .hibernation_mode = 0,
> +#else
> .gfp_mask = GFP_HIGHUSER_MOVABLE,
> + .hibernation_mode = 1,
> +#endif
> .priority = DEF_PRIORITY,
> .may_writepage = 1,
> .may_unmap = 1,
> .may_swap = 1,
> - .hibernation_mode = 1,
> };
> struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask);
> struct task_struct *p = current;
> @@ -3597,6 +3602,20 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim)
> }
> #endif /* CONFIG_HIBERNATION */
>
> +#ifdef CONFIG_SHRINK_MEMORY
> +int sysctl_shrink_memory;
> +/* This is the entry point for system-wide shrink memory
> ++via /proc/sys/vm/shrink_memory */
> +int sysctl_shrinkmem_handler(struct ctl_table *table, int write,
> + void __user *buffer, size_t *length, loff_t *ppos)
> +{

Check if *buffer contains "1". If the value is not "1" return -EINVAL.

The check can be done using function proc_dointvec_minmax().

Best regards

Heinrich Schuchardt

> + if (write)
> + shrink_all_memory(totalram_pages);
> +
> + return 0;
> +}
> +#endif
> +
> /* It's optimal to keep kswapds on the same CPUs as their memory, but
> not required for correctness. So if the last cpu in a node goes
> away, we get changed to run anywhere: as the first one comes back,
>

2015-07-03 18:39:31

by Johannes Weiner

[permalink] [raw]

Subject: Re: [PATCH 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory feature

On Fri, Jul 03, 2015 at 06:50:07PM +0530, Pintu Kumar wrote:
> This patch provides 2 things:
> 1. Add new control called shrink_memory in /proc/sys/vm/.
> This control can be used to aggressively reclaim memory system-wide
> in one shot from the user space. A value of 1 will instruct the
> kernel to reclaim as much as totalram_pages in the system.
> Example: echo 1 > /proc/sys/vm/shrink_memory
>
> 2. Enable shrink_all_memory API in kernel with new CONFIG_SHRINK_MEMORY.
> Currently, shrink_all_memory function is used only during hibernation.
> With the new config we can make use of this API for non-hibernation case
> also without disturbing the hibernation case.
>
> The detailed paper was presented in Embedded Linux Conference, Mar-2015
> http://events.linuxfoundation.org/sites/events/files/slides/
> %5BELC-2015%5D-System-wide-Memory-Defragmenter.pdf
>
> Scenarios were this can be used and helpful are:
> 1) Can be invoked just after system boot-up is finished.

The allocator automatically reclaims when memory is needed, that's why
the metrics quoted in those slides, free pages and fragmentation level,
don't really mean much. We don't care how much memory is free or how
fragmented it is UNTIL somebody actually asks for it. The only metric
that counts is the allocation success ratio (and possibly the latency).

> 2) Can be invoked just before entering entire system suspend.

Why is that? Suspend already allocates as much as it needs to create
the system image.

> 3) Can be invoked from kernel when order-4 pages starts failing.

We have compaction for that, and compaction invokes page reclaim
automatically to satisfy its need for free pages.

> 4) Can be helpful to completely avoid or delay the kerenl OOM condition.

That's not how OOM works. An OOM is triggered when there is demand for
memory but no more pages to reclaim, telling the kernel to look harder
will not change that.

> 5) Can be developed as a system-tool to quickly defragment entire system
> from user space, without the need to kill any application.

Again, the kernel automatically reclaims and compacts memory on demand.
If the existing mechanisms don't do this properly, and you have actual
problems with them, they should be reported and fixed, not bypassed.
But the metrics you seem to base this change on are not representative
of something that should matter in practice.

2015-07-05 12:33:20

by Johannes Weiner

[permalink] [raw]

Subject: Re: [PATCH 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory feature

On Sat, Jul 04, 2015 at 06:04:37AM +0000, PINTU KUMAR wrote:
> >On Fri, Jul 03, 2015 at 06:50:07PM +0530, Pintu Kumar wrote:
> >> This patch provides 2 things:
> >> 1. Add new control called shrink_memory in /proc/sys/vm/.
> >> This control can be used to aggressively reclaim memory system-wide
> >> in one shot from the user space. A value of 1 will instruct the
> >> kernel to reclaim as much as totalram_pages in the system.
> >> Example: echo 1 > /proc/sys/vm/shrink_memory
> >>
> >> 2. Enable shrink_all_memory API in kernel with new CONFIG_SHRINK_MEMORY.
> >> Currently, shrink_all_memory function is used only during hibernation.
> >> With the new config we can make use of this API for non-hibernation case
> >> also without disturbing the hibernation case.
> >>
> >> The detailed paper was presented in Embedded Linux Conference, Mar-2015
> >> http://events.linuxfoundation.org/sites/events/files/slides/
> >> %5BELC-2015%5D-System-wide-Memory-Defragmenter.pdf
> >>
> >> Scenarios were this can be used and helpful are:
> >> 1) Can be invoked just after system boot-up is finished.
> >
> >The allocator automatically reclaims when memory is needed, that's why
> >the metrics quoted in those slides, free pages and fragmentation level,
> >don't really mean much. We don't care how much memory is free or how
> >fragmented it is UNTIL somebody actually asks for it. The only metric
> >that counts is the allocation success ratio (and possibly the latency).
>
> Yes, the allocator automatically reclaims memory but in the
> slowpath. Also it reclaims only to satisfy the current allocation
> needs. That means for all future higher-order allocations the system
> will be entering slowpath again and again. Over a point of time
> (with multiple application launch), the higher-orders (2^4 and
> above) will be gone. The system entering slowpath means that the
> first allocation attempt has already failed. Then in slowpath the
> sequence is: kswapd -> compaction -> then direct reclaim. Thus
> entering slowpath again and again will be a costly operation.
>
> Thus keeping free memory ready in higher-order pages will be helpful
> for succeeding first allocation attempt.

High order allocation fastpath sounds like a bad idea, especially on
embedded devices. It takes a lot of work to create higher order
pages, so anything that relies on being able to allocate them
frequently and quickly is going to be very expensive.

But even if you need higher order pages on a regular pages, compaction
is *way* more efficient and directed than what you are proposing. My
phone has 2G of memory, which is over half a million of pages. What
would it do to my battery life if you told the VM on a regular basis
to scan the LRUs until it has reclaimed half a million pages?

> The scenario that is discussed here is about: Invoking shrink_memory
> from user space, as soon as the system boot is finished. Because as
> per my observation, the buffer+caches that is accumulated during
> boot-up is not very helpful for the system for later application
> launch. Thus reclaiming all memory in shot after the boot-up will
> help grab higher-order pages and freeing lots of memory. Also the
> reclaimed memory stays in as actual free memory. The cached that
> gets accumulated after the application launch will be having more
> hits. It is like a little advanced version of drop_caches.

The buffers and cache are trivial to reclaim and compact, so that
shouldn't affect allocation success at all. And even allocation
latency should be reasonable.

drop_caches is a development/debugging tool for kernel developers, not
a tool to implement userspace memory management. If you find you need
to use it on a regular basis because of performance issues, then
please file a bug report.

> >> 2) Can be invoked just before entering entire system suspend.
> >
> >Why is that? Suspend already allocates as much as it needs to create
>
> >the system image.
>
> Sorry, but I think you got it wrong here. We are not talking about
> snapshot image creation part that comes under hibernation. We are
> talking about the mobile world, where the system gets suspended when
> it is kept idle for longer time. The hibernation part does not comes
> here. The idea is that the shrink_memory can be best utilized when
> the system is not doing any useful stuffs and going from idle to
> suspend. In this scenario, we can check the state of free memory and
> perform the system-wide reclaim if necessary. Thus when the system
> resume again, it will have enough memory as free. Again, this is
> mainly for embedded world where hibernation is not enabled. For
> normal world, it already does it during hibernation snapshot image
> creation.

The reason they are suspending is to conserve energy, now? This is an
outrageous amount of work you propose should be done when the system
goes idle. Generally, proactive work tends to be less efficient than
on-demand work due to overproduction, so the more power-restrained
your system, the lazier and just-in-time you should be.

If your higher-order allocation latency really is an issue, at least
use targetted background compaction. But again, everybody would be
better off if you didn't rely on frequent higher-order allocations,
because they require a lot of CPU-intensive work that consumes a lot
of power, whether you schedule that work on-demand or proactively.

> >> 3) Can be invoked from kernel when order-4 pages starts failing.
> >
> >We have compaction for that, and compaction invokes page reclaim
>
> >automatically to satisfy its need for free pages.
>
> It is not always true. Compaction may not be always
> successful. Again it is related to slowpath. When order-4 starts
> failing very often that means all higher-orders becomes 0. Thus
> system will be entering slowpath again and again, doing swap,
> compaction, reclaim most of the time. And even for compaction,
> there is a knob in user space to call compaction from user space:
> #echo 1 > /proc/sys/vm/compact_memory

At least that's not a cache-destructive operation and just compacts
already free pages but, just like drop_caches, you shouldn't ever have
to use this in production.

> >> 4) Can be helpful to completely avoid or delay the kerenl OOM condition.
> >
> >That's not how OOM works. An OOM is triggered when there is demand for
> >memory but no more pages to reclaim, telling the kernel to look harder
> >will not change that.
>
> >
> Yes, I know this. I am not talking about calling shrink_memory after OOM.
>
> Rather much before OOM when the first attempt of higher-order starts failing.
> This will delay the OOM to a much later stage.

That's not how OOM works *at all*. OOM happens when all the pages are
tied up in places where they can't be reclaimed. It has nothing to do
with fragmentation (OOM is not even defined for higher order pages) or
reclaim timing (since reclaim can't reclaim unreclaimable pages. heh).

You're really not making a lot of sense here.

> >> 5) Can be developed as a system-tool to quickly defragment entire system
> >> from user space, without the need to kill any application.
> >
> >Again, the kernel automatically reclaims and compacts memory on demand.
> >If the existing mechanisms don't do this properly, and you have actual
> >problems with them, they should be reported and fixed, not bypassed.
> >But the metrics you seem to base this change on are not representative
>
> >of something that should matter in practice.
>
> It is not always guaranteed that compaction/reclaim
> _did_some_progress_ always yield some results on the fly. It takes
> sometime to get sync with the free memory. Thus keeping the free
> list ready before hand will be much more helpful.

We can always make compaction more aggressive with certain GFP flags
and tell it to wait for delayed memory frees etc.

> Anyways, the use case here is to develop a system utility which can
> perform compaction/reclaim/compaction aggressively. Its an
> additional idea that somebody interested can develop.

I'm having a hard time seeing a clear usecase from your proposal, and
the implementation is too heavyhanded and destructive to be generally
useful as a memory management tool in real life.

2015-07-05 08:46:31

Sorry, for late reply.

> -----Original Message-----
> From: Mel Gorman [mailto:[email protected]]
> Sent: Wednesday, July 22, 2015 7:36 PM
> To: PINTU KUMAR
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; [email protected]; linux-
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]
> Subject: Re: [PATCH v3 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory
> feature
>
> On Wed, Jul 22, 2015 at 06:33:26PM +0530, PINTU KUMAR wrote:
> > Dear Mel, thank you very much for your comments and suggestions.
> > I will drop this one and look on further improving direct_reclaim and
> > compaction.
> > Just few more comments below before I close.
> >
> > Also, during this patch, I feel that the hibernation_mode part in
> > shrink_all_memory can be corrected.
> > So, can I separately submit the below patch?
> > That is instead of hard-coding the hibernation_mode, we can get
> > hibernation status using:
> > system_entering_hibernation()
> >
> > Please let me know your suggestion about this changes.
> >
> > -#ifdef CONFIG_HIBERNATION
> > +#if defined CONFIG_HIBERNATION || CONFIG_SHRINK_MEMORY
>
I was talking about only the following case.
Instead of hard coding the hibernation_mode in shrink_all_memory,
We can set it at runtime.

- .hibernation_mode = 1,

+ if (system_entering_hibernation())
+ sc.hibernation_mode = 1;
+ else
+ sc.hibernation_mode = 0;

The PM owners should confirm if this is ok.
Once confirmed, I will submit the full patch set.

+> This appears to be a patch on top of "Add /proc/sys/vm/shrink_memory feature"
> so I do not see what would be separately submitted that would make sense.
>
And we don't need to have /proc/sys/vm/shrink_memory patch for this.

However, if required, we can also expose shrink_all_memory() outside the
hibernation using the CONFIG_SHRINK_MEMORY.
Otherwise, we can neglect other changes.

> --
> Mel Gorman
> SUSE Labs

2015-07-29 12:08:54

by Johannes Weiner

[permalink] [raw]

Subject: Re: [PATCH v3 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory feature

On Wed, Jul 29, 2015 at 10:41:10AM +0530, PINTU KUMAR wrote:
> I was talking about only the following case.
> Instead of hard coding the hibernation_mode in shrink_all_memory,
> We can set it at runtime.
>
> - .hibernation_mode = 1,
>
> + if (system_entering_hibernation())
> + sc.hibernation_mode = 1;
> + else
> + sc.hibernation_mode = 0;

Nobody outside hibernation uses this function (and likely never will).
The hardcoding is fine.