On Fri, Feb 07, 2014 at 01:13:32PM -0500, Johannes Weiner wrote:
> On Fri, Feb 07, 2014 at 12:55:37PM -0500, Rik van Riel wrote:
> > On 02/07/2014 12:40 PM, Johannes Weiner wrote:
> >
> > >@@ -59,6 +60,9 @@ int drop_caches_sysctl_handler(ctl_table *table, int write,
> > > if (ret)
> > > return ret;
> > > if (write) {
> > >+ printk_ratelimited(KERN_INFO "%s (%d): dropped kernel caches: %d\n",
> > >+ current->comm, task_pid_nr(current),
> > >+ sysctl_drop_caches);
> > > if (sysctl_drop_caches & 1)
> > > iterate_supers(drop_pagecache_sb, NULL);
> > > if (sysctl_drop_caches & 2)
> > >
> >
> > Would it be better to print this after the operation
> > has completed?
>
> It would make more sense grammatically :-) Either way is fine with me,
> updated below to inform after the fact.
>
> ---
> From: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
> Date: Fri, 12 Oct 2012 14:30:54 +0200
> Subject: [patch] drop_caches: add some documentation and info message
>
> There is plenty of anecdotal evidence and a load of blog posts
> suggesting that using "drop_caches" periodically keeps your system
> running in "tip top shape". Perhaps adding some kernel documentation
> will increase the amount of accurate data on its use.
>
> If we are not shrinking caches effectively, then we have real bugs.
> Using drop_caches will simply mask the bugs and make them harder to
> find, but certainly does not fix them, nor is it an appropriate
> "workaround" to limit the size of the caches. On the contrary, there
> have been bug reports on issues that turned out to be misguided use of
> cache dropping.
>
> Dropping caches is a very drastic and disruptive operation that is
> good for debugging and running tests, but if it creates bug reports
> from production use, kernel developers should be aware of its use.
>
> Add a bit more documentation about it, and add a little KERN_NOTICE.
>
> [akpm@xxxxxxxxxxxxxxxxxxxx: checkpatch fixes]
> Signed-off-by: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Michal Hocko <mhocko@xxxxxxx>
> Acked-by: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
> Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>
> ---
> Documentation/sysctl/vm.txt | 33 +++++++++++++++++++++++++++------
> fs/drop_caches.c | 4 ++++
> 2 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> index d614a9b6a280..36278c610a5f 100644
> --- a/Documentation/sysctl/vm.txt
> +++ b/Documentation/sysctl/vm.txt
> @@ -175,18 +175,39 @@ Setting this to zero disables periodic writeback altogether.
>
> drop_caches
>
> -Writing to this will cause the kernel to drop clean caches, dentries and
> -inodes from memory, causing that memory to become free.
> +Writing to this will cause the kernel to drop clean caches, as well as
> +reclaimable slab objects like dentries and inodes. Once dropped, their
> +memory becomes free.
>
> To free pagecache:
> echo 1 > /proc/sys/vm/drop_caches
> -To free dentries and inodes:
> +To free reclaimable slab objects (includes dentries and inodes):
> echo 2 > /proc/sys/vm/drop_caches
> -To free pagecache, dentries and inodes:
> +To free slab objects and pagecache:
> echo 3 > /proc/sys/vm/drop_caches
>
> -As this is a non-destructive operation and dirty objects are not freeable, the
> -user should run `sync' first.
> +This is a non-destructive operation and will not free any dirty objects.
> +To increase the number of objects freed by this operation, the user may run
> +`sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the
> +number of dirty objects on the system and create more candidates to be
> +dropped.
> +
> +This file is not a means to control the growth of the various kernel caches
> +(inodes, dentries, pagecache, etc...) These objects are automatically
> +reclaimed by the kernel when memory is needed elsewhere on the system.
> +
> +Use of this file can cause performance problems. Since it discards cached
> +objects, it may cost a significant amount of I/O and CPU to recreate the
> +dropped objects, especially if they were under heavy use. Because of this,
> +use outside of a testing or debugging environment is not recommended.
> +
> +You may see informational messages in your kernel log when this file is
> +used:
> +
> + cat (1234): dropped kernel caches: 3
> +
> +These are informational only. They do not mean that anything is wrong
> +with your system.
>
> ==============================================================
>
> diff --git a/fs/drop_caches.c b/fs/drop_caches.c
> index 9fd702f5bfb2..02ae3386e08f 100644
> --- a/fs/drop_caches.c
> +++ b/fs/drop_caches.c
> @@ -5,6 +5,7 @@
> #include <linux/kernel.h>
> #include <linux/mm.h>
> #include <linux/fs.h>
> +#include <linux/ratelimit.h>
> #include <linux/writeback.h>
> #include <linux/sysctl.h>
> #include <linux/gfp.h>
> @@ -63,6 +64,9 @@ int drop_caches_sysctl_handler(ctl_table *table, int write,
> iterate_supers(drop_pagecache_sb, NULL);
> if (sysctl_drop_caches & 2)
> drop_slab();
> + printk_ratelimited(KERN_INFO "%s (%d): dropped kernel caches: %d\n",
Just a nitpick here:
s/printk_ratelimited(KERN_INFO ...)/pr_info_ratelimited(...)
Acked-by: Rafael Aquini <aquini@xxxxxxxxxx>
> + current->comm, task_pid_nr(current),
> + sysctl_drop_caches);
> }
> return 0;
> }
> --
> 1.8.5.3
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxx. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>