On Wednesday 04 April 2007 09:31, Michal Piotrowski wrote:
Con Kolivas napisał(a):
On Wednesday 04 April 2007 08:20, Michal Piotrowski wrote:
Michal Piotrowski napisał(a):
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5-mm4
/m m-oops
http://www.stardust.webpages.pl
was bogus. Fix it.
Fix exiting recalc_task_prio without p-array being updated.
Microoptimisation courtesy of Dmitry Adamushko [EMAIL PROTECTED]
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
Index: linux
p!
Try this patch please?
---
Fix exiting recalc_task_prio without p->array being updated.
Microoptimisation courtesy of Dmitry Adamushko <[EMAIL PROTECTED]>
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/sched.c | 13 ++---
1 file changed, 6 insertions(+), 7
-array being updated.
Microoptimisation courtesy of Dmitry Adamushko [EMAIL PROTECTED]
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
Index: linux-2.6.21-rc5-mm3/kernel/sched.c
On Thursday 29 March 2007 15:50, Mike Galbraith wrote:
> On Thu, 2007-03-29 at 09:44 +1000, Con Kolivas wrote:
> + * This contains a bitmap for each dynamic priority level with empty slots
> + * for the valid priorities each different nice level can have. It allows
> + * us to stagg
On Saturday 31 March 2007 19:28, Xenofon Antidides wrote:
> For long time now I use windows to work
> problems. I cannot play wine games with audio, I
> cannot sample video, I cannot use skype, I cannot play
> midi. And even linux only things I try do I cannot
> share my X, I cannot use more than
On Thursday 29 March 2007 18:18, Mike Galbraith wrote:
> Rereading to make sure I wasn't unclear anywhere...
>
> On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote:
> > I don't see what a < 95% load really means.
>
> Egad. Here I'm pondering the numbers and light load as I'm typing, and
> my
On Thursday 29 March 2007 21:22, Ingo Molnar wrote:
> [ A quick guess: could SD's substandard interactivity in this test be
> due to the SMP migration logic inconsistencies Mike noticed? This is
> an SMP system and the hackbench workload is very scheduling intense
> and tasks are frequently
ed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/sched.c | 97 +++--
1 file changed, 60 insertions(+), 37 deletions(-)
Index: linux-2.6.21-rc5-mm3/kernel/sched.c
===
--- linu
Staircase Deadline improvements.
Nice is better distributed for waking tasks with a per-static-prio prio_level.
SCHED_RR tasks were not being requeued on expiration.
Tighten up accounting.
Fix comment style.
Microoptimisation courtesy of Dmitry Adamushko [EMAIL PROTECTED]
Signed-off-by: Con
On Thursday 29 March 2007 21:22, Ingo Molnar wrote:
[ A quick guess: could SD's substandard interactivity in this test be
due to the SMP migration logic inconsistencies Mike noticed? This is
an SMP system and the hackbench workload is very scheduling intense
and tasks are frequently
On Saturday 31 March 2007 19:28, Xenofon Antidides wrote:
For long time now I use windows to work
problems. I cannot play wine games with audio, I
cannot sample video, I cannot use skype, I cannot play
midi. And even linux only things I try do I cannot
share my X, I cannot use more than one
On Thursday 29 March 2007 18:18, Mike Galbraith wrote:
Rereading to make sure I wasn't unclear anywhere...
On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote:
I don't see what a 95% load really means.
Egad. Here I'm pondering the numbers and light load as I'm typing, and
my fingers
On Thursday 29 March 2007 15:50, Mike Galbraith wrote:
On Thu, 2007-03-29 at 09:44 +1000, Con Kolivas wrote:
+ * This contains a bitmap for each dynamic priority level with empty slots
+ * for the valid priorities each different nice level can have. It allows
+ * us to stagger the slots where
On Thursday 29 March 2007 02:37, Con Kolivas wrote:
> I'm cautiously optimistic that we're at the thin edge of the bugfix wedge
> now.
My neck condition got a lot worse today. I'm forced offline for a week and
will be uncontactable.
--
-ck
-
To unsubscribe from this list: send th
On Thursday 29 March 2007 04:48, Ingo Molnar wrote:
> hm, how about the questions Mike raised (there were a couple of cases of
> friction between 'the design as documented and announced' and 'the code
> as implemented')? As far as i saw they were still largely unanswered -
> but let me know if
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
Documentation/sysctl/kernel.txt |8 ++--
kernel/sched.c | 73 +---
2 files changed, 58 insertions(+), 23 deletions(-)
Index: linux-2.6.21-rc5-mm2/ke
-by: Con Kolivas [EMAIL PROTECTED]
---
Documentation/sysctl/kernel.txt |8 ++--
kernel/sched.c | 73 +---
2 files changed, 58 insertions(+), 23 deletions(-)
Index: linux-2.6.21-rc5-mm2/kernel/sched.c
On Thursday 29 March 2007 04:48, Ingo Molnar wrote:
hm, how about the questions Mike raised (there were a couple of cases of
friction between 'the design as documented and announced' and 'the code
as implemented')? As far as i saw they were still largely unanswered -
but let me know if they
On Thursday 29 March 2007 02:37, Con Kolivas wrote:
I'm cautiously optimistic that we're at the thin edge of the bugfix wedge
now.
My neck condition got a lot worse today. I'm forced offline for a week and
will be uncontactable.
--
-ck
-
To unsubscribe from this list: send the line
Add comprehensive documentation of the Staircase Deadline cpu scheduler design.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
Documentation/sched-design.txt | 240 +++--
1 file changed, 234 insertions(+), 6 deletions(-)
Index: linux-2.6.21-
Remove the TASK_NONINTERACTIVE flag as it will no longer be used.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
fs/pipe.c |7 +--
include/linux/sched.h |3 +--
2 files changed, 2 insertions(+), 8 deletions(-)
Index: linux-2.6.21-rc5-sd/fs/
Remove the sleep_avg field from proc output as it will be removed from the
task_struct.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
fs/proc/array.c |2 --
1 file changed, 2 deletions(-)
Index: linux-2.6.21-rc5-sd/fs/proc/a
The practice of renicing kernel threads to negative nice values is of
questionable benefit at best, and at worst leads to larger latencies when
kernel threads are busy on behalf of other tasks.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/workqueue.c |2 --
1 file chan
What follows is a clean major iteration of the (now) Staircase Deadline cpu
scheduler.
Changes from RSDL v0.33:
- All accounting is moved to tasks in nanosecond resolution removing
requirement for Rotation component entirely
- list_splice_tail is no longer required; dropped
- Nicer nice with
On Tuesday 27 March 2007 01:28, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> Subsequent to that Con suggested testing a refactored RSDL patch. That
> patch seemed to work on the machine at hand, so tests have been
> submitted for all the affected machines.
>
>
On Monday 26 March 2007 15:11, Al Boldi wrote:
> Con Kolivas wrote:
> > Ok this one is heavily tested. Please try it when you find the time.
>
> It's better, but still skewed. Try two chew.c's; they account 80% each.
>
> > ---
> > Currently we only do cpu account
On Monday 26 March 2007 15:00, Mike Galbraith wrote:
> On Mon, 2007-03-26 at 11:00 +1000, Con Kolivas wrote:
> > This is just for testing at the moment! The reason is the size of this
> > patch.
>
> (no testing done yet, but I have a couple comments)
>
> > In the int
On Monday 26 March 2007 15:00, Mike Galbraith wrote:
On Mon, 2007-03-26 at 11:00 +1000, Con Kolivas wrote:
This is just for testing at the moment! The reason is the size of this
patch.
(no testing done yet, but I have a couple comments)
In the interest of evolution, I've taken the RSDL
On Monday 26 March 2007 15:11, Al Boldi wrote:
Con Kolivas wrote:
Ok this one is heavily tested. Please try it when you find the time.
It's better, but still skewed. Try two chew.c's; they account 80% each.
---
Currently we only do cpu accounting to userspace based on what is
actually
On Tuesday 27 March 2007 01:28, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Subsequent to that Con suggested testing a refactored RSDL patch. That
patch seemed to work on the machine at hand, so tests have been
submitted for all the affected machines.
What follows is a clean major iteration of the (now) Staircase Deadline cpu
scheduler.
Changes from RSDL v0.33:
- All accounting is moved to tasks in nanosecond resolution removing
requirement for Rotation component entirely
- list_splice_tail is no longer required; dropped
- Nicer nice with
The practice of renicing kernel threads to negative nice values is of
questionable benefit at best, and at worst leads to larger latencies when
kernel threads are busy on behalf of other tasks.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/workqueue.c |2 --
1 file changed, 2
Remove the sleep_avg field from proc output as it will be removed from the
task_struct.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
fs/proc/array.c |2 --
1 file changed, 2 deletions(-)
Index: linux-2.6.21-rc5-sd/fs/proc/array.c
Remove the TASK_NONINTERACTIVE flag as it will no longer be used.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
fs/pipe.c |7 +--
include/linux/sched.h |3 +--
2 files changed, 2 insertions(+), 8 deletions(-)
Index: linux-2.6.21-rc5-sd/fs/pipe.c
Add comprehensive documentation of the Staircase Deadline cpu scheduler design.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
Documentation/sched-design.txt | 240 +++--
1 file changed, 234 insertions(+), 6 deletions(-)
Index: linux-2.6.21-rc5-sd
On Saturday 24 March 2007 04:57, Tim Chen wrote:
> On Fri, 2007-03-23 at 13:40 +1100, Con Kolivas wrote:
> > Volanomark is a purely yield() semantic dependant workload (as
> > discussed many times previously). In the earlier form of RSDL I
> > softened the effect of sched_yi
This is just for testing at the moment! The reason is the size of this patch.
In the interest of evolution, I've taken the RSDL cpu scheduler and increased
the resolution of the task timekeeping to nanosecond resolution. This removes
the need for the runqueue rotation component entirely out of
On Monday 26 March 2007 09:01, Con Kolivas wrote:
> On Monday 26 March 2007 03:14, malc wrote:
> > On Mon, 26 Mar 2007, Con Kolivas wrote:
> > > On Monday 26 March 2007 01:19, malc wrote:
> > Erm... i just looked at the code and suddenly it stopped making any sense
> &
On Monday 26 March 2007 03:14, malc wrote:
> On Mon, 26 Mar 2007, Con Kolivas wrote:
> > On Monday 26 March 2007 01:19, malc wrote:
> >> On Mon, 26 Mar 2007, Con Kolivas wrote:
> >>> So before we go any further with this patch, can you try the following
> >
On Monday 26 March 2007 08:49, Con Kolivas wrote:
> On Monday 26 March 2007 04:28, Torsten Kaiser wrote:
> > On 3/24/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > kernel/sched.c | 51
> > > +++ 1
On Monday 26 March 2007 04:28, Torsten Kaiser wrote:
> On 3/24/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > kernel/sched.c | 51
> > +++ 1 file changed, 51
> > insertions(+)
>
> 2.6.21-rc4-mm1 also fails for me
On Monday 26 March 2007 01:19, malc wrote:
> On Mon, 26 Mar 2007, Con Kolivas wrote:
> > So before we go any further with this patch, can you try the following
> > one and see if this simple sanity check is enough?
>
> Sure (compiling the kernel now), too bad old a
On Monday 26 March 2007 00:57, malc wrote:
> On Mon, 26 Mar 2007, Con Kolivas wrote:
> > On Sunday 25 March 2007 23:06, malc wrote:
> >> On Sun, 25 Mar 2007, Con Kolivas wrote:
> >>> On Sunday 25 March 2007 21:46, Con Kolivas wrote:
> >>>> On Sunday 25
On Sunday 25 March 2007 23:06, malc wrote:
> On Sun, 25 Mar 2007, Con Kolivas wrote:
> > On Sunday 25 March 2007 21:46, Con Kolivas wrote:
> >> On Sunday 25 March 2007 21:34, malc wrote:
> >>> On Sun, 25 Mar 2007, Ingo Molnar wrote:
> >>>
On Sunday 25 March 2007 22:32, Gene Heskett wrote:
> On Sunday 25 March 2007, Con Kolivas wrote:
> >On Sunday 25 March 2007 21:46, Con Kolivas wrote:
> >> On Sunday 25 March 2007 21:34, malc wrote:
> >> > On Sun, 25 Mar 2007, Ingo Molnar wrote:
> >> >
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
> On Sunday 25 March 2007 21:34, malc wrote:
> > On Sun, 25 Mar 2007, Ingo Molnar wrote:
> > > * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > >> For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
>
On Sunday 25 March 2007 21:34, malc wrote:
> On Sun, 25 Mar 2007, Ingo Molnar wrote:
> > * Con Kolivas <[EMAIL PROTECTED]> wrote:
> >> For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
> >
> > we want to do this - and we should do this to the v
On Sunday 25 March 2007 17:51, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
>
> we want to do this - and we should do this to the vanilla scheduler
> first and check the results. I've back-me
On Sunday 25 March 2007 17:51, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do this - and we should do this to the vanilla scheduler
first and check the results. I've back-merged the patch to before RSDL
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do this - and we should do this to the vanilla scheduler
first and check the results. I've
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do this - and we should do
On Sunday 25 March 2007 22:32, Gene Heskett wrote:
On Sunday 25 March 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33
On Sunday 25 March 2007 23:06, malc wrote:
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel
On Monday 26 March 2007 00:57, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 23:06, malc wrote:
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo
On Monday 26 March 2007 01:19, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
So before we go any further with this patch, can you try the following
one and see if this simple sanity check is enough?
Sure (compiling the kernel now), too bad old axiom that testing can not
confirm
On Monday 26 March 2007 04:28, Torsten Kaiser wrote:
On 3/24/07, Con Kolivas [EMAIL PROTECTED] wrote:
kernel/sched.c | 51
+++ 1 file changed, 51
insertions(+)
2.6.21-rc4-mm1 also fails for me.
I tried pure 2.6.21-rc4-mm1, +hotfixes
On Monday 26 March 2007 08:49, Con Kolivas wrote:
On Monday 26 March 2007 04:28, Torsten Kaiser wrote:
On 3/24/07, Con Kolivas [EMAIL PROTECTED] wrote:
kernel/sched.c | 51
+++ 1 file changed, 51
insertions(+)
2.6.21-rc4-mm1 also
On Monday 26 March 2007 03:14, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 01:19, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
So before we go any further with this patch, can you try the following
one and see if this simple sanity check is enough
On Monday 26 March 2007 09:01, Con Kolivas wrote:
On Monday 26 March 2007 03:14, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 01:19, malc wrote:
Erm... i just looked at the code and suddenly it stopped making any sense
at all:
p-last_ran = rq
This is just for testing at the moment! The reason is the size of this patch.
In the interest of evolution, I've taken the RSDL cpu scheduler and increased
the resolution of the task timekeeping to nanosecond resolution. This removes
the need for the runqueue rotation component entirely out of
On Saturday 24 March 2007 04:57, Tim Chen wrote:
On Fri, 2007-03-23 at 13:40 +1100, Con Kolivas wrote:
Volanomark is a purely yield() semantic dependant workload (as
discussed many times previously). In the earlier form of RSDL I
softened the effect of sched_yield but other changes since
On Sunday 25 March 2007 11:59, Con Kolivas wrote:
> For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
>
> ---
> Currently we only do cpu accounting to userspace based on what is actually
> happening precisely on each tick. The accuracy of that accounting gets
> p
resolution we can accurately track user cpu, nice cpu and idle cpu
if we move the accounting to update_cpu_clock with a nanosecond cpu_usage_stat
entry. This increases overhead slightly but avoids the problem of tick
aliasing errors making accounting unreliable.
Signed-off-by: Con Kolivas <[EM
resolution we can accurately track user cpu, nice cpu and idle cpu
if we move the accounting to update_cpu_clock with a nanosecond cpu_usage_stat
entry. This increases overhead slightly but avoids the problem of tick
aliasing errors making accounting unreliable.
Signed-off-by: Con Kolivas [EMAIL
On Sunday 25 March 2007 11:59, Con Kolivas wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
---
Currently we only do cpu accounting to userspace based on what is actually
happening precisely on each tick. The accuracy of that accounting gets
progressively worse the lower
On Saturday 24 March 2007 08:45, Con Kolivas wrote:
> On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
> > Andy Whitcroft wrote:
> > > Con Kolivas wrote:
> > >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> > >>> Ok, I hav
On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Con Kolivas wrote:
> >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> >>> Ok, I have yet a third x86_64 machine is is blowing up with the latest
> >>> 2.6
Latest version of RSDL cpu scheduler (v0.33) for various trees available here:
http://ck.kolivas.org/patches/staircase-deadline/
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Latest version of RSDL cpu scheduler (v0.33) for various trees available here:
http://ck.kolivas.org/patches/staircase-deadline/
--
-ck
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Con Kolivas wrote:
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Ok, I have yet a third x86_64 machine is is blowing up with the latest
2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
2.6.21-rc4-mm1
On Saturday 24 March 2007 08:45, Con Kolivas wrote:
On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Con Kolivas wrote:
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Ok, I have yet a third x86_64 machine is is blowing up with the
latest 2.6.21-rc4
rio should not be set by realtime or SCHED_BATCH tasks.
Correct that, and microoptimise the code around setting best_static_prio.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/sched.c | 103 +++--
1 file changed, 71 insertio
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> Ok, I have yet a third x86_64 machine is is blowing up with the latest
> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
> so I have just fired off a set of tests
On Friday 23 March 2007 15:39, Mike Galbraith wrote:
> On Fri, 2007-03-23 at 09:50 +1100, Con Kolivas wrote:
> > Now to figure out some meaningful cheap way of improving this accounting.
>
> The accounting is easy iff tick resolution is good enough, the deadline
> mechanism
On 23/03/07, Tim Chen <[EMAIL PROTECTED]> wrote:
Con,
I've tried running Volanomark and found a 80% regression
with RSDL 0.31 scheduler on 2.6.21-rc4 on a 2 socket Core 2 quad cpu
system (4 cpus per socket, 8 cpus for system).
The results are sensitive to rr_interval. Using Con's patch to
Thanks for taking the time to actually look at the code. All audits are most
welcome!.
On Thursday 22 March 2007 18:07, Mike Galbraith wrote:
> This is a rather long message, and isn't directed at anyone in
> particular, it's for others who may be digging into their own problems
> with RSDL, and
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Con Kolivas wrote:
> >> On Thursday 22 March 2007 20:48, Andy Whitcroft wrote:
> >>> Andy Whitcroft wrote:
> >>>> Andy Whitcroft wrote:
> >>>>> Andrew
All code reviews are most welcome indeed!
On Thursday 22 March 2007 20:18, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > Actually, the numbers are an interesting curiosity point, but not as
> > interesting as the fact that the deadline mechanism isn't kicking in.
>
> it's
On Thursday 22 March 2007 20:48, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Andy Whitcroft wrote:
> >> Andrew Morton wrote:
> >>> Temporarily at
> >>>
> >>> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
> >>>
> >>> Will appear later at
> >>>
> >>>
> >>>
On Thursday 22 March 2007 20:48, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Andy Whitcroft wrote:
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
All code reviews are most welcome indeed!
On Thursday 22 March 2007 20:18, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Actually, the numbers are an interesting curiosity point, but not as
interesting as the fact that the deadline mechanism isn't kicking in.
it's not just
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Con Kolivas wrote:
On Thursday 22 March 2007 20:48, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Andy Whitcroft wrote:
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1
Thanks for taking the time to actually look at the code. All audits are most
welcome!.
On Thursday 22 March 2007 18:07, Mike Galbraith wrote:
This is a rather long message, and isn't directed at anyone in
particular, it's for others who may be digging into their own problems
with RSDL, and
On 23/03/07, Tim Chen [EMAIL PROTECTED] wrote:
Con,
I've tried running Volanomark and found a 80% regression
with RSDL 0.31 scheduler on 2.6.21-rc4 on a 2 socket Core 2 quad cpu
system (4 cpus per socket, 8 cpus for system).
The results are sensitive to rr_interval. Using Con's patch to
On Friday 23 March 2007 15:39, Mike Galbraith wrote:
On Fri, 2007-03-23 at 09:50 +1100, Con Kolivas wrote:
Now to figure out some meaningful cheap way of improving this accounting.
The accounting is easy iff tick resolution is good enough, the deadline
mechanism is harder. I did the quota
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Ok, I have yet a third x86_64 machine is is blowing up with the latest
2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
so I have just fired off a set of tests across
should not be set by realtime or SCHED_BATCH tasks.
Correct that, and microoptimise the code around setting best_static_prio.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c | 103 +++--
1 file changed, 71 insertions(+), 32 deletions
On Thursday 22 March 2007 10:36, Andrew Morton wrote:
> On Thu, 22 Mar 2007 04:29:44 +1100
>
> Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Further improve the deterministic nature of the RSDL cpu scheduler and
> > make the rr_interval tunable.
>
> I might actuall
this
major rotation was.
Reimplement SCHED_BATCH using this check.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/sched.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
Index: linux-2.6.21-rc4-mm1/kernel/s
On Thursday 22 March 2007 11:24, Con Kolivas wrote:
> On Thursday 22 March 2007 10:48, Jeffrey Hundstad wrote:
> > Artur Skawina wrote:
> > > Con Kolivas wrote:
> > >> Note no interactive boost idea here.
> > >>
> > >> Patch is for 2.6
On Thursday 22 March 2007 10:48, Jeffrey Hundstad wrote:
> Artur Skawina wrote:
> > Con Kolivas wrote:
> >> Note no interactive boost idea here.
> >>
> >> Patch is for 2.6.21-rc4-mm1. I have not spent the time trying to bring
> >> other bases in sync.
in normal_prio() may prevent oopses on
bootup on large SMP due to forking off the idle task.
Other minor cleanups.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
Documentation/sysctl/kernel.txt | 12 +
kernel/sched.c | 94 ++--
in normal_prio() may prevent oopses on
bootup on large SMP due to forking off the idle task.
Other minor cleanups.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
Documentation/sysctl/kernel.txt | 12 +
kernel/sched.c | 94 ++--
kernel
On Thursday 22 March 2007 10:48, Jeffrey Hundstad wrote:
Artur Skawina wrote:
Con Kolivas wrote:
Note no interactive boost idea here.
Patch is for 2.6.21-rc4-mm1. I have not spent the time trying to bring
other bases in sync.
I've tried RSDLv.31+this on 2.6.20.3 as i'm not tracking
On Thursday 22 March 2007 11:24, Con Kolivas wrote:
On Thursday 22 March 2007 10:48, Jeffrey Hundstad wrote:
Artur Skawina wrote:
Con Kolivas wrote:
Note no interactive boost idea here.
Patch is for 2.6.21-rc4-mm1. I have not spent the time trying to bring
other bases in sync
this
major rotation was.
Reimplement SCHED_BATCH using this check.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
Index: linux-2.6.21-rc4-mm1/kernel/sched.c
On Thursday 22 March 2007 10:36, Andrew Morton wrote:
On Thu, 22 Mar 2007 04:29:44 +1100
Con Kolivas [EMAIL PROTECTED] wrote:
Further improve the deterministic nature of the RSDL cpu scheduler and
make the rr_interval tunable.
I might actually need to drop RSDL from next -mm, see if those
On Saturday 17 March 2007 23:28, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > We're obviously disagreeing on what heuristics are [...]
>
> that could very well be so - it would be helpful if you could provide
> your own rough definition for the te
On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Despite the claims to the contrary, RSDL does not have _less_
> > heuristics, it does not have _any_. It's purely entitlement based.
>
> RSDL still has heuristics ve
301 - 400 of 1175 matches
Mail list logo
