dynamic sched timeslices

dynamic sched timeslices

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 1073 bytes --]

Hi,

attached patch allows userspace to tune the scheduling timeslices.
It can be used for a couple of things:
* Tune a workload for batch processing:
  You'd probably wnat to use long timeslices in order to not reschedule
  as often to make good use of your CPU caches
* Tune a workload for interactive use:
  Under load, you may want to reduce the scedulilng latencies by using
  shorter timeslices (and there are situations where the interactiviy
  tweak -- even if they were perfect -- can't save you).
* Tune the ration betweeen maximum and minimum timeslices to make
  nice much nicer e.g.

The patch exports /proc/sys/kernel/max_timeslice and min_timeslice,
unites are us. It also exports HZ (readonly).
The patch implementes the desktop boot parameter which introduces 
shorter timeslices.

Patch is from andrea and is in our 2.4 tree; 2.6 port was done by me and
straightforward. 

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #1.2: dynamic-timeslice.diff --]
[-- Type: text/plain, Size: 3827 bytes --]

diff -uNrp linux-2.6.4/include/linux/sched.h linux-2.6.4.sched/include/linux/sched.h
--- linux-2.6.4/include/linux/sched.h	2004-03-11 21:01:41.746772792 +0100
+++ linux-2.6.4.sched/include/linux/sched.h	2004-03-11 21:24:41.208062800 +0100
@@ -176,6 +176,7 @@ extern unsigned long cache_decay_ticks;
 #define	MAX_SCHEDULE_TIMEOUT	LONG_MAX
 extern signed long FASTCALL(schedule_timeout(signed long timeout));
 asmlinkage void schedule(void);
+extern int max_timeslice, min_timeslice;
 
 struct namespace;
 
diff -uNrp linux-2.6.4/include/linux/sysctl.h linux-2.6.4.sched/include/linux/sysctl.h
--- linux-2.6.4/include/linux/sysctl.h	2004-03-11 21:01:41.747772640 +0100
+++ linux-2.6.4.sched/include/linux/sysctl.h	2004-03-11 21:32:32.968344336 +0100
@@ -134,6 +134,9 @@ enum
 	KERN_KDB=64,		/* int: kdb on/off */
 	KERN_S390_HZ_TIMER=65,  /* int: hz timer on or off */
 	KERN_DUMP=66,		/* directory: dump parameters */
+	KERN_MAXTIMESLICE=67,	/* int: nice -20 max timeslice */
+	KERN_MINTIMESLICE=68,	/* int: nice +19 min timeslice */
+	KERN_HZ=69,		/* unsigned long: interal kernel HZ */
 };
 
 
diff -uNrp linux-2.6.4/kernel/sched.c linux-2.6.4.sched/kernel/sched.c
--- linux-2.6.4/kernel/sched.c	2004-03-11 21:01:41.752771880 +0100
+++ linux-2.6.4.sched/kernel/sched.c	2004-03-11 22:06:26.166251272 +0100
@@ -79,12 +79,19 @@ EXPORT_SYMBOL(dump_oncpu);
 /*
  * These are the 'tuning knobs' of the scheduler:
  *
- * Minimum timeslice is 10 msecs, default timeslice is 100 msecs,
- * maximum timeslice is 200 msecs. Timeslices get refilled after
- * they expire.
- */
-#define MIN_TIMESLICE		( 10 * HZ / 1000)
-#define MAX_TIMESLICE		(200 * HZ / 1000)
+ * Minimum timeslice is 10 msecs, default timeslice is 150 msecs,
+ * maximum timeslice is 300 msecs. Timeslices get refilled after
+ * they expire. 
+ */
+#define __MIN_TIMESLICE		  10000
+#define __MAX_TIMESLICE		 300000
+#define __MIN_TIMESLICE_DESKTOP	   2000
+#define __MAX_TIMESLICE_DESKTOP	  60000
+/* the sysctl values are exported in usec units to userspace */
+int max_timeslice = __MAX_TIMESLICE, min_timeslice = __MIN_TIMESLICE;
+#define MAX_TIMESLICE ((max_timeslice * HZ + 999999) / 1000000)
+#define MIN_TIMESLICE ((min_timeslice * HZ + 999999) / 1000000)
+
 #define ON_RUNQUEUE_WEIGHT	 30
 #define CHILD_PENALTY		 95
 #define PARENT_PENALTY		100
@@ -2965,3 +2972,13 @@ task_t *kdb_cpu_curr(int cpu)
 	return(cpu_curr(cpu));
 }
 #endif
+
+static int __init init_desktop(char *str)
+{
+	min_timeslice = __MIN_TIMESLICE_DESKTOP;
+	max_timeslice = __MAX_TIMESLICE_DESKTOP;
+	return 1;
+}
+__setup("desktop", init_desktop);
+
+
diff -uNrp linux-2.6.4/kernel/sysctl.c linux-2.6.4.sched/kernel/sysctl.c
--- linux-2.6.4/kernel/sysctl.c	2004-03-11 21:01:37.983344920 +0100
+++ linux-2.6.4.sched/kernel/sysctl.c	2004-03-11 21:36:26.253879544 +0100
@@ -167,6 +167,7 @@ static void register_proc_table(ctl_tabl
 static void unregister_proc_table(ctl_table *, struct proc_dir_entry *);
 #endif
 
+static unsigned long __HZ = HZ;
 /* The default sysctl tables: */
 
 static ctl_table root_table[] = {
@@ -642,6 +643,30 @@ static ctl_table kern_table[] = {
 		.mode		= 0444,
 		.proc_handler	= &proc_dointvec,
 	},
+	{
+		.ctl_name	= KERN_MAXTIMESLICE, 
+		.procname	= "max-timeslice",
+		.data		=  &max_timeslice,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
+	{
+		.ctl_name	= KERN_MINTIMESLICE, 
+		.procname	= "min-timeslice",
+		.data		= &min_timeslice,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
+	{
+		.ctl_name	= KERN_HZ, 
+		.procname	= "HZ",
+		.data		= &__HZ,
+		.maxlen		= sizeof(long),
+		.mode		= 0444,
+		.proc_handler	= &proc_dointvec,
+	},
 	{ .ctl_name = 0 }
 };
 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: dynamic sched timeslices

[Christoph Hellwig]

On Mon, Mar 15, 2004 at 11:42:01PM +0100, Kurt Garloff wrote:
> Hi,
> 
> attached patch allows userspace to tune the scheduling timeslices.
> It can be used for a couple of things:
> * Tune a workload for batch processing:
>   You'd probably wnat to use long timeslices in order to not reschedule
>   as often to make good use of your CPU caches
> * Tune a workload for interactive use:
>   Under load, you may want to reduce the scedulilng latencies by using
>   shorter timeslices (and there are situations where the interactiviy
>   tweak -- even if they were perfect -- can't save you).
> * Tune the ration betweeen maximum and minimum timeslices to make
>   nice much nicer e.g.
> 
> The patch exports /proc/sys/kernel/max_timeslice and min_timeslice,
> unites are us. It also exports HZ (readonly).
> The patch implementes the desktop boot parameter which introduces 
> shorter timeslices.
> 
> Patch is from andrea and is in our 2.4 tree; 2.6 port was done by me and
> straightforward. 

Remove the silly desktop boot parameter and the patch looks basically
okay to me.

I remember we had a more complete patch to allow tuning the scheduler
through sysctls in -mm once, though.  Questions is why that one wasn't
merged and if the same reasons apply to a 'light' version.

Re: dynamic sched timeslices

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 665 bytes --]

Hi Christoph,

quick response!
On Mon, Mar 15, 2004 at 10:59:39PM +0000, Christoph Hellwig wrote:
> Remove the silly desktop boot parameter and the patch looks basically
> okay to me.

See attachment.

> I remember we had a more complete patch to allow tuning the scheduler
> through sysctls in -mm once, though.  Questions is why that one wasn't
> merged and if the same reasons apply to a 'light' version.

Hmm, I fail to remember unfortunately. Probably it had too many knobs.
Andrew?

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #1.2: dynamic-timeslice-2.diff --]
[-- Type: text/plain, Size: 3366 bytes --]

diff -uNr linux-2.6.4/include/linux/sched.h linux-2.6.4.dyn-timeslice/include/linux/sched.h
--- linux-2.6.4/include/linux/sched.h	2004-03-16 00:03:52.000000000 +0100
+++ linux-2.6.4.dyn-timeslice/include/linux/sched.h	2004-03-16 00:05:14.000000000 +0100
@@ -176,6 +176,7 @@
 #define	MAX_SCHEDULE_TIMEOUT	LONG_MAX
 extern signed long FASTCALL(schedule_timeout(signed long timeout));
 asmlinkage void schedule(void);
+extern int max_timeslice, min_timeslice;
 
 struct namespace;
 
diff -uNr linux-2.6.4/include/linux/sysctl.h linux-2.6.4.dyn-timeslice/include/linux/sysctl.h
--- linux-2.6.4/include/linux/sysctl.h	2004-03-16 00:03:52.000000000 +0100
+++ linux-2.6.4.dyn-timeslice/include/linux/sysctl.h	2004-03-16 00:07:31.000000000 +0100
@@ -134,6 +134,9 @@
 	KERN_KDB=64,		/* int: kdb on/off */
 	KERN_S390_HZ_TIMER=65,  /* int: hz timer on or off */
 	KERN_DUMP=66,		/* directory: dump parameters */
+	KERN_MAXTIMESLICE=67,	/* int: nice -20 max timeslice */
+	KERN_MINTIMESLICE=68,	/* int: nice +19 min timeslice */
+	KERN_HZ=69,		/* unsigned long: internal kernel HZ */
 };
 
 
diff -uNr linux-2.6.4/kernel/sched.c linux-2.6.4.dyn-timeslice/kernel/sched.c
--- linux-2.6.4/kernel/sched.c	2004-03-16 00:03:52.000000000 +0100
+++ linux-2.6.4.dyn-timeslice/kernel/sched.c	2004-03-16 00:06:14.000000000 +0100
@@ -79,12 +79,17 @@
 /*
  * These are the 'tuning knobs' of the scheduler:
  *
- * Minimum timeslice is 10 msecs, default timeslice is 100 msecs,
- * maximum timeslice is 200 msecs. Timeslices get refilled after
- * they expire.
- */
-#define MIN_TIMESLICE		( 10 * HZ / 1000)
-#define MAX_TIMESLICE		(200 * HZ / 1000)
+ * Minimum timeslice is 10 msecs, default timeslice is 150 msecs,
+ * maximum timeslice is 300 msecs. Timeslices get refilled after
+ * they expire. 
+ */
+#define __MIN_TIMESLICE		  10000
+#define __MAX_TIMESLICE		 300000
+/* the sysctl values are exported in usec units to userspace */
+int max_timeslice = __MAX_TIMESLICE, min_timeslice = __MIN_TIMESLICE;
+#define MAX_TIMESLICE ((max_timeslice * HZ + 999999) / 1000000)
+#define MIN_TIMESLICE ((min_timeslice * HZ + 999999) / 1000000)
+
 #define ON_RUNQUEUE_WEIGHT	 30
 #define CHILD_PENALTY		 95
 #define PARENT_PENALTY		100
diff -uNr linux-2.6.4/kernel/sysctl.c linux-2.6.4.dyn-timeslice/kernel/sysctl.c
--- linux-2.6.4/kernel/sysctl.c	2004-03-16 00:03:52.000000000 +0100
+++ linux-2.6.4.dyn-timeslice/kernel/sysctl.c	2004-03-16 00:05:14.000000000 +0100
@@ -167,6 +167,7 @@
 static void unregister_proc_table(ctl_table *, struct proc_dir_entry *);
 #endif
 
+static unsigned long __HZ = HZ;
 /* The default sysctl tables: */
 
 static ctl_table root_table[] = {
@@ -642,6 +643,30 @@
 		.mode		= 0444,
 		.proc_handler	= &proc_dointvec,
 	},
+	{
+		.ctl_name	= KERN_MAXTIMESLICE, 
+		.procname	= "max-timeslice",
+		.data		=  &max_timeslice,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
+	{
+		.ctl_name	= KERN_MINTIMESLICE, 
+		.procname	= "min-timeslice",
+		.data		= &min_timeslice,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
+	{
+		.ctl_name	= KERN_HZ, 
+		.procname	= "HZ",
+		.data		= &__HZ,
+		.maxlen		= sizeof(long),
+		.mode		= 0444,
+		.proc_handler	= &proc_dointvec,
+	},
 	{ .ctl_name = 0 }
 };
 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: dynamic sched timeslices

[Andrew Morton]

Kurt Garloff <garloff@suse.de> wrote:
>
> > I remember we had a more complete patch to allow tuning the scheduler
> > through sysctls in -mm once, though.  Questions is why that one wasn't
> > merged and if the same reasons apply to a 'light' version.
> 
> Hmm, I fail to remember unfortunately. Probably it had too many knobs.
> Andrew?

It had a zillion knobs, and was mainly for developers.

Your patch didn't come with any subjective or measured testing results.  In
theory, the scheduler should magically tune itself to the current workload.
If your patch is indeed necessary then this may point at a bug in the
current CPU scheduler.

Please tell us more...

Re: dynamic sched timeslices

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

Hi Andrew,

On Mon, Mar 15, 2004 at 03:40:42PM -0800, Andrew Morton wrote:
> Kurt Garloff <garloff@suse.de> wrote:
> Your patch didn't come with any subjective or measured testing results. 

We've done some measurements with 2.4 and O(1):
* HZ=1000 cost about 1.5% perf. on a kernel compile (plus problems
  with lost timer ticks)
* Seting the scheduling timeslices from 1ms--30ms rather than 10ms thr
  300ms cost another ~3% kernel compile performance
* Depending on the workload the effect can be larger. Numbercrunching
  would come to mind.
* Some people are unhappy that nice is not nice enough.

> In
> theory, the scheduler should magically tune itself to the current workload.

No, the computer can not take the decision whether a machine is sitting
in a machine room and mainly doing batch processing or whether it's used
by somebody sitting in front of it as workstation.

You can add heuristics and look at the load and sleep_avg of processes,
and scale timeslices dynamically, but these heuristics are IMVHO a very 
bad idea. They tend to break in subtle ways and disallow to reproduce
benchmark numbers etc.

I do know that the priorites do ensure that interactive processes have
some bonus, so even with long timeslices a system should be usable.
But heuristics fail and some situtaions with high load just can't be 
solved by such bonuses.

> If your patch is indeed necessary then this may point at a bug in the
> current CPU scheduler.

No, why should it? How should the computer know what the user wants if
he has no way to tell him?

It's a classical throughput vs. latency tradeoff and the patch allows
the user to set it. I'm sure some people are willing to have long
timeslices in order to gain 5% and don't care about the sched latencies.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: dynamic sched timeslices

[Con Kolivas]

On Tue, 16 Mar 2004 10:36 pm, Kurt Garloff wrote:
> On Mon, Mar 15, 2004 at 03:40:42PM -0800, Andrew Morton wrote:
> > Your patch didn't come with any subjective or measured testing results.

> We've done some measurements with 2.4 and O(1):
> * HZ=1000 cost about 1.5% perf. on a kernel compile (plus problems
>   with lost timer ticks)
> * Seting the scheduling timeslices from 1ms--30ms rather than 10ms thr
>   300ms cost another ~3% kernel compile performance
> * Depending on the workload the effect can be larger. Numbercrunching
>   would come to mind.

2.4 O(1) effects do not directly apply with 2.6

Dropping Hz will save you performance for sure on 2.6.

Changing the timeslices in 2.6 will be disappointing, though. Although the 
apparent timeslice of nice 0 tasks is 102ms, interactive tasks round robin at 
10ms. If you drop the timeslice to 10ms you will not improve the interactive 
feel but you will speed up expiration instead which will almost certainly 
worsen interactive feel. If you drop timeslices below 10ms you will get 
significant cache trashing and drop in performance (which your 2.4 results 
confirm).

Increasing timeslices does benefit pure number crunching workloads. The 
benchmarking I've done using cache intensive workloads (which are the most 
likely to benefit) show you are chasing diminishing returns, though. You can 
mathematically model them based on the fact that keeping a task bound to a 
cpu instead of shifting it to another cpu on SMP saves about 2ms processing 
time on P4. Suffice to say the benefit is only worth it if you do nothing but 
cpu intensive things, and becomes virtually insignificant beyond 200ms. On 
other architecture with longer cache decays you will benefit more; 
arch/i386/mach-voyager seems the longest at 20ms.

>It's a classical throughput vs. latency tradeoff and the patch allows
>the user to set it. I'm sure some people are willing to have long
>timeslices in order to gain 5% and don't care about the sched latencies.

As you can see from the above it is not that clear cut.

Con

Re: dynamic sched timeslices

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]

Hi Con,

On Wed, Mar 17, 2004 at 12:13:37AM +1100, Con Kolivas wrote:
> 2.4 O(1) effects do not directly apply with 2.6
> 
> Dropping Hz will save you performance for sure on 2.6.
> 
> Changing the timeslices in 2.6 will be disappointing, though. Although the 
> apparent timeslice of nice 0 tasks is 102ms, interactive tasks round robin at 
> 10ms. If you drop the timeslice to 10ms you will not improve the interactive 
> feel but you will speed up expiration instead which will almost certainly 
> worsen interactive feel. 

If you have a system with an easy workload (say one clear CPU hog and
one interactive job), things are easy. The fact that you preempt the
not-yet expired CPU hog is enough.
That's easy, and that worked with 2.4 O(1) (if tweaked a bit to estimate
interactiveness better, see other patch) and it works with 2.6.

Things start to get difficult if you have something like a calculation
program with a non-multithreaded GUI. It will look like a CPU hog and
still you'd like to see it responsive. Now add a second CPU hog.

The kernel can not fix this problem, but it can limit the damage by 
not having too long timeslices.

There are other scenarios where the preemption will not solve all
problems.
Think two interactive processes, one playing audio, another one being
your shell. The audio player may take the CPU for extended periods of
times occasionally to decode the next N ogg frames. You still want the
shell to react promptly, but it can't ... Thus you wish the timeslice
not being too long.

Thus you'll set them not too long for desktop kind of machines to
not have to rely completely on the interactiveness estimator.

> If you drop timeslices below 10ms you will get 
> significant cache trashing and drop in performance (which your 2.4 results 
> confirm).

No doubt. Don't overdo it. It's a tradeoff. If you impact throughput too
much, you'll not enjoy the short latency ;-)

> Increasing timeslices does benefit pure number crunching workloads. The 
> benchmarking I've done using cache intensive workloads (which are the most 
> likely to benefit) show you are chasing diminishing returns, though. You can 
> mathematically model them based on the fact that keeping a task bound to a 
> cpu instead of shifting it to another cpu on SMP saves about 2ms processing 
> time on P4. Suffice to say the benefit is only worth it if you do nothing but 
> cpu intensive things, and becomes virtually insignificant beyond 200ms. On 
> other architecture with longer cache decays you will benefit more; 
> arch/i386/mach-voyager seems the longest at 20ms.

That's why I think we should offer the tunables.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>             [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux: SUSE Labs (Head)        <garloff@suse.de>    [SUSE Nuernberg, DE]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: dynamic sched timeslices

[Con Kolivas]

On Wed, 17 Mar 2004 01:29 am, Kurt Garloff wrote:
> Hi Con,
>
> On Wed, Mar 17, 2004 at 12:13:37AM +1100, Con Kolivas wrote:
> > 2.4 O(1) effects do not directly apply with 2.6
> >
> > Dropping Hz will save you performance for sure on 2.6.
> >
> > Changing the timeslices in 2.6 will be disappointing, though. Although
> > the apparent timeslice of nice 0 tasks is 102ms, interactive tasks round
> > robin at 10ms. If you drop the timeslice to 10ms you will not improve the
> > interactive feel but you will speed up expiration instead which will
> > almost certainly worsen interactive feel.
>
> If you have a system with an easy workload (say one clear CPU hog and
> one interactive job), things are easy. The fact that you preempt the
> not-yet expired CPU hog is enough.
> That's easy, and that worked with 2.4 O(1) (if tweaked a bit to estimate
> interactiveness better, see other patch) and it works with 2.6.
>
> Things start to get difficult if you have something like a calculation
> program with a non-multithreaded GUI. It will look like a CPU hog and
> still you'd like to see it responsive. Now add a second CPU hog.
>
> The kernel can not fix this problem, but it can limit the damage by
> not having too long timeslices.
>
> There are other scenarios where the preemption will not solve all
> problems.
> Think two interactive processes, one playing audio, another one being
> your shell. The audio player may take the CPU for extended periods of
> times occasionally to decode the next N ogg frames. You still want the
> shell to react promptly, but it can't ... Thus you wish the timeslice
> not being too long.
>
> Thus you'll set them not too long for desktop kind of machines to
> not have to rely completely on the interactiveness estimator.

I'm not arguing with your logic I'm saying you will ruin the estimator in the 
process because it isn't just about timeslices and preemption. Ultimately 
you're still only give me theoretical cases which are exactly what were my 
test cases during development. Find a test case that you can prove it does 
something rather than a theoretical one. Oh and a test case should be one 
where it is the cpu scheduler that is responsible, not one where you're 
fixing problems due to poor hardware config with alsa, oss, IDE, dma settings 
etc.

> > If you drop timeslices below 10ms you will get
> > significant cache trashing and drop in performance (which your 2.4
> > results confirm).
>
> No doubt. Don't overdo it. It's a tradeoff. If you impact throughput too
> much, you'll not enjoy the short latency ;-)
>
> > Increasing timeslices does benefit pure number crunching workloads. The
> > benchmarking I've done using cache intensive workloads (which are the
> > most likely to benefit) show you are chasing diminishing returns, though.
> > You can mathematically model them based on the fact that keeping a task
> > bound to a cpu instead of shifting it to another cpu on SMP saves about
> > 2ms processing time on P4. Suffice to say the benefit is only worth it if
> > you do nothing but cpu intensive things, and becomes virtually
> > insignificant beyond 200ms. On other architecture with longer cache
> > decays you will benefit more; arch/i386/mach-voyager seems the longest at
> > 20ms.
>
> That's why I think we should offer the tunables.

If your workload is so dedicated to just number crunching it isn't hard to add 
a zero to maximum timeslice in kernel/sced.c. Then again this is just 
semantics about how to tune it so I don't really care, but I'm sure the 
maintainer wants proof that changing it shows some real world improvement.

Con

Re: dynamic sched timeslices

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

Hi Con,

On Wed, Mar 17, 2004 at 07:45:02AM +1100, Con Kolivas wrote:
> > That's why I think we should offer the tunables.
> 
> If your workload is so dedicated to just number crunching it isn't hard to add 
> a zero to maximum timeslice in kernel/sced.c. 

Of course I can compile a custom kernel for myself and tune all sorts of
things. But this is not the way most Linux users want to use Linux any
more. Actually that's a long time ago.

Best regards,
-- 
Kurt Garloff                   <kurt@garloff.de>             [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux: SUSE Labs (Head)        <garloff@suse.de>    [SUSE Nuernberg, DE]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: dynamic sched timeslices

[Andrew Morton]

Kurt Garloff <garloff@suse.de> wrote:
>
> Hi Con,
> 
> On Wed, Mar 17, 2004 at 07:45:02AM +1100, Con Kolivas wrote:
> > > That's why I think we should offer the tunables.
> > 
> > If your workload is so dedicated to just number crunching it isn't hard to add 
> > a zero to maximum timeslice in kernel/sced.c. 
> 
> Of course I can compile a custom kernel for myself and tune all sorts of
> things. But this is not the way most Linux users want to use Linux any
> more. Actually that's a long time ago.
> 

I don't think we should be averse to offering a couple of nice high-level
scheduler tunables.  But I do think we should have testing results which
clearly show that they provide some benefit, and we should agree that the
scheduler cannot provide the same benefit automagically.

Apologies in advance if we've seen those testing results and I missed it.

Re: dynamic sched timeslices

[Con Kolivas]

Quoting Andrew Morton <akpm@osdl.org>:

> Kurt Garloff <garloff@suse.de> wrote:
> >
> > Hi Con,
> > 
> > On Wed, Mar 17, 2004 at 07:45:02AM +1100, Con Kolivas wrote:
> > > > That's why I think we should offer the tunables.
> > > 
> > > If your workload is so dedicated to just number crunching it isn't hard
> to add 
> > > a zero to maximum timeslice in kernel/sced.c. 
> > 
> > Of course I can compile a custom kernel for myself and tune all sorts of
> > things. But this is not the way most Linux users want to use Linux any
> > more. Actually that's a long time ago.
> > 
> 
> I don't think we should be averse to offering a couple of nice high-level
> scheduler tunables.  But I do think we should have testing results which
> clearly show that they provide some benefit, and we should agree that the
> scheduler cannot provide the same benefit automagically.
> 
> Apologies in advance if we've seen those testing results and I missed it.

Well that reply takes my message out of context. I'm not averse to tunables - if
they do something.

The only evidence Kurt has shown so far is that he can decrease throughput. The
rest is theoretical based on a scheduler that isn't the 2.6 kernel.

Con

Re: dynamic sched timeslices

[Timothy Miller]

Kurt Garloff wrote:
> Hi,
> 
> attached patch allows userspace to tune the scheduling timeslices.
> It can be used for a couple of things:
> * Tune a workload for batch processing:
>   You'd probably wnat to use long timeslices in order to not reschedule
>   as often to make good use of your CPU caches
> * Tune a workload for interactive use:
>   Under load, you may want to reduce the scedulilng latencies by using
>   shorter timeslices (and there are situations where the interactiviy
>   tweak -- even if they were perfect -- can't save you).
> * Tune the ration betweeen maximum and minimum timeslices to make
>   nice much nicer e.g.
> 
> The patch exports /proc/sys/kernel/max_timeslice and min_timeslice,
> unites are us. It also exports HZ (readonly).
> The patch implementes the desktop boot parameter which introduces 
> shorter timeslices.
> 
> Patch is from andrea and is in our 2.4 tree; 2.6 port was done by me and
> straightforward. 
> 
> Regards,

If this doesn't change the total amount of CPU a process can get but 
lets a process tweak how its CPU time is divided up, then it sounds 
wonderful.

Re: dynamic sched timeslices

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Hi Timothy,

On Tue, Mar 16, 2004 at 10:03:39AM -0500, Timothy Miller wrote:
> If this doesn't change the total amount of CPU a process can get but 
> lets a process tweak how its CPU time is divided up, then it sounds 
> wonderful.

It let's the sysadming tune how often the kernel switches between 
processes competing for the CPU.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: dynamic sched timeslices

[Pavel Machek]

Hi!

> attached patch allows userspace to tune the scheduling timeslices.
> It can be used for a couple of things:
> * Tune a workload for batch processing:
>   You'd probably wnat to use long timeslices in order to not reschedule
>   as often to make good use of your CPU caches
> * Tune a workload for interactive use:
>   Under load, you may want to reduce the scedulilng latencies by using
>   shorter timeslices (and there are situations where the interactiviy
>   tweak -- even if they were perfect -- can't save you).
> * Tune the ration betweeen maximum and minimum timeslices to make
>   nice much nicer e.g.

If you make ration much bigger, you are going to see
priority inversion issues. Some kind of "boost priority when in
kernel" would be needed...

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms