Re: add /proc/sys/kernel/cache_decay_ticks

Re: add /proc/sys/kernel/cache_decay_ticks

[Andi Kleen]

David Mosberger <davidm@napali.hpl.hp.com> writes:

> /proc/sys/kernel/cache_decay_ticks allows runtime tuning of the
> scheduler.  The earlier patch collided with the C99-ification of the
> file, so here is a retransmit.

Funny, I did a similar patch for 2.4 a short time ago. But I would
suggest one change before you merge that to mainline. The variable
is currently used like this:

#define CAN_MIGRATE_TASK(p,rq,this_cpu)                                 \
        ((jiffies - (p)->last_run > cache_decay_ticks) &&       \o

Which means 0 means 1 jiffie. For a tunable it would be useful to be 
able to turn it off completely, which means the > needs to be replaced
with a >=. Unfortunately this requires changes in the architectures
too to subtract one. But it would make it more useful. I would do
the change before exposing it.

-Andi

Re: add /proc/sys/kernel/cache_decay_ticks

[David Mosberger]

>>>>> On 19 Jun 2003 00:05:18 +0200, Andi Kleen <ak@suse.de> said:

  Andi> David Mosberger <davidm@napali.hpl.hp.com> writes:
  >> /proc/sys/kernel/cache_decay_ticks allows runtime tuning of the
  >> scheduler.  The earlier patch collided with the C99-ification of
  >> the file, so here is a retransmit.

  Andi> Funny, I did a similar patch for 2.4 a short time ago. But I
  Andi> would suggest one change before you merge that to
  Andi> mainline. The variable is currently used like this:

  Andi> #define CAN_MIGRATE_TASK(p,rq,this_cpu) \ ((jiffies -
  Andi> (p)->last_run > cache_decay_ticks) && \o

  Andi> Which means 0 means 1 jiffie. For a tunable it would be useful
  Andi> to be able to turn it off completely, which means the > needs
  Andi> to be replaced with a >=. Unfortunately this requires changes
  Andi> in the architectures too to subtract one. But it would make it
  Andi> more useful. I would do the change before exposing it.

I don't see why the two have to be tied together.  I agree it would be
_nice_, but having /proc/sys/kernel/cache_decay_ticks in it's current
form is much better than nothing at all.

	--david

Re: add /proc/sys/kernel/cache_decay_ticks

[Andi Kleen]

> I don't see why the two have to be tied together.  I agree it would be
> _nice_, but having /proc/sys/kernel/cache_decay_ticks in it's current
> form is much better than nothing at all.

The problem is that when you change it later with the sysctl you have a subtle
user visible change, breaking existing users.

-Andi

add /proc/sys/kernel/cache_decay_ticks

[David Mosberger]

/proc/sys/kernel/cache_decay_ticks allows runtime tuning of the
scheduler.  The earlier patch collided with the C99-ification of the
file, so here is a retransmit.

	--david

diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h
--- a/include/linux/sysctl.h	Wed Jun 18 13:32:49 2003
+++ b/include/linux/sysctl.h	Wed Jun 18 13:32:49 2003
@@ -130,6 +130,7 @@
 	KERN_PIDMAX=55,		/* int: PID # limit */
   	KERN_CORE_PATTERN=56,	/* string: pattern for core-file names */
 	KERN_PANIC_ON_OOPS=57,  /* int: whether we will panic on an oops */
+	KERN_CACHEDECAYTICKS=58, /* ulong: value for cache_decay_ticks (EXPERIMENTAL!) */
 };
 
 
diff -Nru a/kernel/sysctl.c b/kernel/sysctl.c
--- a/kernel/sysctl.c	Wed Jun 18 13:32:49 2003
+++ b/kernel/sysctl.c	Wed Jun 18 13:32:49 2003
@@ -551,6 +551,16 @@
 		.mode		= 0644,
 		.proc_handler	= &proc_dointvec,
 	},
+#ifdef CONFIG_SMP
+	{
+		.ctl_name	= KERN_CACHEDECAYTICKS,
+		.procname	= "cache_decay_ticks",
+		.data		= &cache_decay_ticks,
+		.maxlen		= sizeof(cache_decay_ticks),
+		.mode		= 0644,
+		.proc_handler	= &proc_doulongvec_minmax,
+	},
+#endif
 	{ .ctl_name = 0 }
 };