] for spotting more smp balancing
problems.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
Index: linux-2.6.21-rc7-sd/kernel/sched.c
On Monday 23 April 2007 00:27, Michael Gerdau wrote:
Anyway the more important part is... Can you test this patch please? Dump
all the other patches I sent you post 045. Michael, if you could test too
please?
Have it up running for 40 minutes now and my perljobs show a constant
cpu
Yet another significant bugfix for SMP balancing was just posted for the
staircase deadline cpu scheduler which improves behaviour dramatically on any
SMP machine.
Thanks to Willy Tarreau for noticing more bugs.
As requested was a version in the Makefile so this version of the patch
adds
On Monday 23 April 2007 00:22, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 10:18:32PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 21:42, Con Kolivas wrote:
Willy I'm still investigating the idle time and fluctuating load as a
separate issue. Is it possible the multiple ocbench
On Sunday 22 April 2007 23:07, Willy Tarreau wrote:
On Sun, Apr 22, 2007 at 10:18:32PM +1000, Con Kolivas wrote:
On Sunday 22 April 2007 21:42, Con Kolivas wrote:
Willy I'm still investigating the idle time and fluctuating load as a
separate issue.
OK.
Is it possible the multiple
On Monday 23 April 2007 03:58, Thomas Backlund wrote:
mån 2007-04-23 klockan 01:03 +1000 skrev Con Kolivas:
Yet another significant bugfix for SMP balancing was just posted for the
staircase deadline cpu scheduler which improves behaviour dramatically on
any SMP machine.
Thanks to Willy
A significant bugfix for SMP balancing was just posted for the staircase
deadline cpu scheduler which improves behaviour dramatically on any SMP
machine.
Thanks to Willy Tarreau for noticing likely fault point.
Also requested was a version in the Makefile so this version of the patch
adds
Typo in comment, 1us not 1ms.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/sched.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21-rc7-sd/kernel/sched.c
===
--- linux-2.6.21-rc7-s
-fix
---
SMP balancing broke on converting time_slice to usecs.
update_cpu_clock is unnecessarily complex and doesn't allow sub usec values.
Thanks to Willy Tarreau <[EMAIL PROTECTED]> for picking up SMP idle anomalies.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/sc
On Saturday 21 April 2007 22:12, Willy Tarreau wrote:
> 2) SD-0.44
>
>Feels good, but becomes jerky at moderately high loads. I've started
>64 ocbench with a 250 ms busy loop and 750 ms sleep time. The system
>always responds correctly but under X, mouse jumps quite a bit and
>
On Sunday 22 April 2007 04:17, Gene Heskett wrote:
> More first impressions of sd-0.44 vs CFS-v4
Thanks Gene.
>
> CFS-v4 is quite smooth in terms of the users experience but after prolonged
> observations approaching 24 hours, it appears to choke the cpu hog off a
> bit even when the system has
On Sunday 22 April 2007 08:54, Denis Vlasenko wrote:
> On Saturday 21 April 2007 18:00, Ingo Molnar wrote:
> > correct. Note that Willy reniced X back to 0 so it had no relevance on
> > his test. Also note that i pointed this change out in the -v4 CFS
> >
> > announcement:
> > || Changes since
On Sunday 22 April 2007 02:00, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > Feels even better, mouse movements are very smooth even under high
> > > load. I noticed that X gets reniced to -19 with this scheduler.
> > > I've not lo
On Saturday 21 April 2007 22:12, Willy Tarreau wrote:
> I promised to perform some tests on your code. I'm short in time right now,
> but I observed behaviours that should be commented on.
> Feels even better, mouse movements are very smooth even under high load.
> I noticed that X gets
On Saturday 21 April 2007 22:12, Willy Tarreau wrote:
> Hi Ingo, Hi Con,
>
> I promised to perform some tests on your code. I'm short in time right now,
> but I observed behaviours that should be commented on.
>
> 1) machine : dual athlon 1533 MHz, 1G RAM, kernel 2.6.21-rc7 + either
> scheduler
A significant bugfix for forking tasks was just posted, so here is an updated
version of the staircase deadline cpu scheduler. This may cause noticeable
behavioural improvements under certain workloads (such as compiling software
with make).
Thanks to Al Boldi for making me check the fork code!
was broken by changing
time_slice to a signed int.
first_time_slice was not being cleared anywhere near often enough.
SCHED_BATCH tasks in the current implementation should advance prio_level
and best_static_prio.
Thanks Al Boldi <[EMAIL PROTECTED]> for making me check the fork code.
Signed-off-b
was broken by changing
time_slice to a signed int.
first_time_slice was not being cleared anywhere near often enough.
SCHED_BATCH tasks in the current implementation should advance prio_level
and best_static_prio.
Thanks Al Boldi [EMAIL PROTECTED] for making me check the fork code.
Signed-off-by: Con
A significant bugfix for forking tasks was just posted, so here is an updated
version of the staircase deadline cpu scheduler. This may cause noticeable
behavioural improvements under certain workloads (such as compiling software
with make).
Thanks to Al Boldi for making me check the fork code!
On Saturday 21 April 2007 22:12, Willy Tarreau wrote:
Hi Ingo, Hi Con,
I promised to perform some tests on your code. I'm short in time right now,
but I observed behaviours that should be commented on.
1) machine : dual athlon 1533 MHz, 1G RAM, kernel 2.6.21-rc7 + either
scheduler Test:
On Saturday 21 April 2007 22:12, Willy Tarreau wrote:
I promised to perform some tests on your code. I'm short in time right now,
but I observed behaviours that should be commented on.
Feels even better, mouse movements are very smooth even under high load.
I noticed that X gets reniced
On Sunday 22 April 2007 02:00, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
Feels even better, mouse movements are very smooth even under high
load. I noticed that X gets reniced to -19 with this scheduler.
I've not looked at the code yet but this looked suspicious
On Sunday 22 April 2007 08:54, Denis Vlasenko wrote:
On Saturday 21 April 2007 18:00, Ingo Molnar wrote:
correct. Note that Willy reniced X back to 0 so it had no relevance on
his test. Also note that i pointed this change out in the -v4 CFS
announcement:
|| Changes since -v3:
||
||
On Sunday 22 April 2007 04:17, Gene Heskett wrote:
More first impressions of sd-0.44 vs CFS-v4
Thanks Gene.
CFS-v4 is quite smooth in terms of the users experience but after prolonged
observations approaching 24 hours, it appears to choke the cpu hog off a
bit even when the system has
On Saturday 21 April 2007 22:12, Willy Tarreau wrote:
2) SD-0.44
Feels good, but becomes jerky at moderately high loads. I've started
64 ocbench with a 250 ms busy loop and 750 ms sleep time. The system
always responds correctly but under X, mouse jumps quite a bit and
typing in
-fix
---
SMP balancing broke on converting time_slice to usecs.
update_cpu_clock is unnecessarily complex and doesn't allow sub usec values.
Thanks to Willy Tarreau [EMAIL PROTECTED] for picking up SMP idle anomalies.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c | 42
Typo in comment, 1us not 1ms.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21-rc7-sd/kernel/sched.c
===
--- linux-2.6.21-rc7-sd.orig
A significant bugfix for SMP balancing was just posted for the staircase
deadline cpu scheduler which improves behaviour dramatically on any SMP
machine.
Thanks to Willy Tarreau for noticing likely fault point.
Also requested was a version in the Makefile so this version of the patch
adds
On Friday 20 April 2007 01:01, Con Kolivas wrote:
> This then allows the maximum rr_interval to be as large as 5000
> milliseconds.
Just for fun, on a core2duo make allnoconfig make -j8 here are the build time
differences (on a 1000HZ config) machine:
16ms:
53.68user 4.81system 0:34.27e
On Friday 20 April 2007 02:15, Mark Lord wrote:
> Con Kolivas wrote:
> > On Thursday 19 April 2007 23:17, Mark Lord wrote:
> >> Con Kolivas wrote:
> >> s go ahead and think up great ideas for other ways of metering out cpu
> >>
> >>> bandwidth for
On Friday 20 April 2007 05:26, Ray Lee wrote:
> On 4/19/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > The one fly in the ointment for
> > linux remains X. I am still, to this moment, completely and utterly
> > stunned at why everyone is trying to find increasin
On Friday 20 April 2007 04:16, Gene Heskett wrote:
> On Thursday 19 April 2007, Con Kolivas wrote:
>
> [and I snipped a good overview]
>
> >So yes go ahead and think up great ideas for other ways of metering out
> > cpu bandwidth for different purposes, but for X, given t
In order to keep raising the standard for comparison for the alternative new
scheduler developments, here is an updated version of the staircase deadline
cpu scheduler.
http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7-sd-0.43.patch
On Thursday 19 April 2007 23:17, Mark Lord wrote:
> Con Kolivas wrote:
> s go ahead and think up great ideas for other ways of metering out cpu
>
> > bandwidth for different purposes, but for X, given the absurd simplicity
> > of renicing, why keep fighting it? Again I reit
More aggressive nice discrimination by the Staircase-Deadline cpu scheduler
means ksoftirqd is getting significantly less cpu than previously. Adjust
nice value accordingly for similar cpu distribution.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/softirq.c |2 +-
timeslices.
Thanks to Peter Zijlstra for help.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/sched.c | 45 +++--
kernel/sysctl.c | 11 ++-
2 files changed, 29 insertions(+), 27 deletions(-)
Index: linux-2.6.21-rc7-s
Update documentation to reflect higher maximum rr_interval.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
Documentation/sysctl/kernel.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21-rc7-sd/Documentation/sysctl/kern
On Thursday 19 April 2007 22:55, Willy Tarreau wrote:
> On Thu, Apr 19, 2007 at 12:12:14PM +1000, Con Kolivas wrote:
> > On Thursday 19 April 2007 10:41, Con Kolivas wrote:
> > > On Thursday 19 April 2007 09:59, Con Kolivas wrote:
> > > > Since there is
CPU
> time by "fiddling with nice levels"? That's what they're there for.
and
Staircase-Deadline:
On Thursday 19 April 2007 09:59, Con Kolivas wrote:
> Remember to renice X to -10 for nicest desktop behaviour :)
[1]The one caveat I can think of is that when you share X sessions ac
On Thursday 19 April 2007 20:22, Nick Piggin wrote:
> On Thu, Apr 19, 2007 at 07:40:04PM +1000, Con Kolivas wrote:
> > On Thursday 19 April 2007 13:22, Nick Piggin wrote:
> > > On Thu, Apr 19, 2007 at 12:12:14PM +1000, Con Kolivas wrote:
> > > > Version 0.42
> &g
On Thursday 19 April 2007 13:22, Nick Piggin wrote:
> On Thu, Apr 19, 2007 at 12:12:14PM +1000, Con Kolivas wrote:
> > Version 0.42
> >
> > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7-sd-0.42.patch
>
> OK, I run some tests later today...
Th
On Thursday 19 April 2007 13:22, Nick Piggin wrote:
On Thu, Apr 19, 2007 at 12:12:14PM +1000, Con Kolivas wrote:
Version 0.42
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7-sd-0.42.patch
OK, I run some tests later today...
Thank you very much.
--
-ck
-
To unsubscribe from
On Thursday 19 April 2007 20:22, Nick Piggin wrote:
On Thu, Apr 19, 2007 at 07:40:04PM +1000, Con Kolivas wrote:
On Thursday 19 April 2007 13:22, Nick Piggin wrote:
On Thu, Apr 19, 2007 at 12:12:14PM +1000, Con Kolivas wrote:
Version 0.42
http://ck.kolivas.org/patches/staircase
they're there for.
and
Staircase-Deadline:
On Thursday 19 April 2007 09:59, Con Kolivas wrote:
Remember to renice X to -10 for nicest desktop behaviour :)
[1]The one caveat I can think of is that when you share X sessions across
multiple users -with a fair cpu scheduler-, having them all nice 0
On Thursday 19 April 2007 22:55, Willy Tarreau wrote:
On Thu, Apr 19, 2007 at 12:12:14PM +1000, Con Kolivas wrote:
On Thursday 19 April 2007 10:41, Con Kolivas wrote:
On Thursday 19 April 2007 09:59, Con Kolivas wrote:
Since there is so much work currently ongoing with alternative cpu
.
Thanks to Peter Zijlstra for help.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c | 45 +++--
kernel/sysctl.c | 11 ++-
2 files changed, 29 insertions(+), 27 deletions(-)
Index: linux-2.6.21-rc7-sd/kernel/sched.c
Update documentation to reflect higher maximum rr_interval.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
Documentation/sysctl/kernel.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21-rc7-sd/Documentation/sysctl/kernel.txt
More aggressive nice discrimination by the Staircase-Deadline cpu scheduler
means ksoftirqd is getting significantly less cpu than previously. Adjust
nice value accordingly for similar cpu distribution.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/softirq.c |2 +-
1 file changed
On Thursday 19 April 2007 23:17, Mark Lord wrote:
Con Kolivas wrote:
s go ahead and think up great ideas for other ways of metering out cpu
bandwidth for different purposes, but for X, given the absurd simplicity
of renicing, why keep fighting it? Again I reiterate that most users of
SD
In order to keep raising the standard for comparison for the alternative new
scheduler developments, here is an updated version of the staircase deadline
cpu scheduler.
http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7-sd-0.43.patch
On Friday 20 April 2007 04:16, Gene Heskett wrote:
On Thursday 19 April 2007, Con Kolivas wrote:
[and I snipped a good overview]
So yes go ahead and think up great ideas for other ways of metering out
cpu bandwidth for different purposes, but for X, given the absurd
simplicity of renicing
On Friday 20 April 2007 05:26, Ray Lee wrote:
On 4/19/07, Con Kolivas [EMAIL PROTECTED] wrote:
The one fly in the ointment for
linux remains X. I am still, to this moment, completely and utterly
stunned at why everyone is trying to find increasingly complex unique
ways to manage X when
On Friday 20 April 2007 02:15, Mark Lord wrote:
Con Kolivas wrote:
On Thursday 19 April 2007 23:17, Mark Lord wrote:
Con Kolivas wrote:
s go ahead and think up great ideas for other ways of metering out cpu
bandwidth for different purposes, but for X, given the absurd
simplicity
On Friday 20 April 2007 01:01, Con Kolivas wrote:
This then allows the maximum rr_interval to be as large as 5000
milliseconds.
Just for fun, on a core2duo make allnoconfig make -j8 here are the build time
differences (on a 1000HZ config) machine:
16ms:
53.68user 4.81system 0:34.27elapsed 170
On Thursday 19 April 2007 10:41, Con Kolivas wrote:
> On Thursday 19 April 2007 09:59, Con Kolivas wrote:
> > Since there is so much work currently ongoing with alternative cpu
> > schedulers, as a standard for comparison with the alternative virtual
> > deadline fair designs
On Thursday 19 April 2007 09:48, Con Kolivas wrote:
> While the Staircase Deadline scheduler has not been completely killed off
> and is still in -mm I would like to fix some outstanding issues that I've
> found since it still serves for comparison with all the upcoming
> scheduler
On Thursday 19 April 2007 09:59, Con Kolivas wrote:
> Since there is so much work currently ongoing with alternative cpu
> schedulers, as a standard for comparison with the alternative virtual
> deadline fair designs I've addressed a few issues in the Staircase Deadline
> cpu sch
Since there is so much work currently ongoing with alternative cpu schedulers,
as a standard for comparison with the alternative virtual deadline fair
designs I've addressed a few issues in the Staircase Deadline cpu scheduler
which improve behaviour likely in a noticeable fashion and released
.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
kernel/sched.c | 61 ++---
1 file changed, 41 insertions(+), 20 deletions(-)
Index: linux-2.6.21-rc7-sd/kernel/s
On Wednesday 18 April 2007 22:33, Con Kolivas wrote:
> On Wednesday 18 April 2007 22:14, Nick Piggin wrote:
> > On Wed, Apr 18, 2007 at 07:33:56PM +1000, Con Kolivas wrote:
> > > On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
> > > > Again, for
On Wednesday 18 April 2007 22:13, Nick Piggin wrote:
> On Wed, Apr 18, 2007 at 11:53:34AM +0200, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > So looking at elapsed time, a granularity of 100ms is just behind the
> > > mainline score. However it is using slightly less user
On Wednesday 18 April 2007 22:14, Nick Piggin wrote:
> On Wed, Apr 18, 2007 at 07:33:56PM +1000, Con Kolivas wrote:
> > On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
> > > Again, for comparison 2.6.21-rc7 mainline:
> > >
> > > 508.87user 32.47system 2:1
On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
> On Tue, Apr 17, 2007 at 11:59:00AM +0200, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > 2.6.21-rc7-cfs-v2
> > > 534.80user 30.92system 2:23.64elapsed 393%CPU
> > > 534.75user 31.01system 2:23.70elapsed 393%CPU
> > >
On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
On Tue, Apr 17, 2007 at 11:59:00AM +0200, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
2.6.21-rc7-cfs-v2
534.80user 30.92system 2:23.64elapsed 393%CPU
534.75user 31.01system 2:23.70elapsed 393%CPU
534.66user
On Wednesday 18 April 2007 22:14, Nick Piggin wrote:
On Wed, Apr 18, 2007 at 07:33:56PM +1000, Con Kolivas wrote:
On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
Again, for comparison 2.6.21-rc7 mainline:
508.87user 32.47system 2:17.82elapsed 392%CPU
509.05user 32.25system 2
On Wednesday 18 April 2007 22:13, Nick Piggin wrote:
On Wed, Apr 18, 2007 at 11:53:34AM +0200, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
So looking at elapsed time, a granularity of 100ms is just behind the
mainline score. However it is using slightly less user time and
On Wednesday 18 April 2007 22:33, Con Kolivas wrote:
On Wednesday 18 April 2007 22:14, Nick Piggin wrote:
On Wed, Apr 18, 2007 at 07:33:56PM +1000, Con Kolivas wrote:
On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
Again, for comparison 2.6.21-rc7 mainline:
508.87user
.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
kernel/sched.c | 61 ++---
1 file changed, 41 insertions(+), 20 deletions(-)
Index: linux-2.6.21-rc7-sd/kernel/sched.c
===
--- linux
Since there is so much work currently ongoing with alternative cpu schedulers,
as a standard for comparison with the alternative virtual deadline fair
designs I've addressed a few issues in the Staircase Deadline cpu scheduler
which improve behaviour likely in a noticeable fashion and released
On Thursday 19 April 2007 09:59, Con Kolivas wrote:
Since there is so much work currently ongoing with alternative cpu
schedulers, as a standard for comparison with the alternative virtual
deadline fair designs I've addressed a few issues in the Staircase Deadline
cpu scheduler which improve
On Thursday 19 April 2007 09:48, Con Kolivas wrote:
While the Staircase Deadline scheduler has not been completely killed off
and is still in -mm I would like to fix some outstanding issues that I've
found since it still serves for comparison with all the upcoming
schedulers.
While still
On Thursday 19 April 2007 10:41, Con Kolivas wrote:
On Thursday 19 April 2007 09:59, Con Kolivas wrote:
Since there is so much work currently ongoing with alternative cpu
schedulers, as a standard for comparison with the alternative virtual
deadline fair designs I've addressed a few issues
Greetings all
Here is the current release of the Staircase cpu scheduler (the original
generation I design that spurned development elsewhere for RSDL), for
2.6.21-rc7
http://ck.kolivas.org/patches/pre-releases/2.6.21-rc7/2.6.21-rc7-ck1/patches/sched-staircase-17.1.patch
To remind people
Greetings all
Here is the current release of the Staircase cpu scheduler (the original
generation I design that spurned development elsewhere for RSDL), for
2.6.21-rc7
http://ck.kolivas.org/patches/pre-releases/2.6.21-rc7/2.6.21-rc7-ck1/patches/sched-staircase-17.1.patch
To remind people
On Monday 16 April 2007 01:05, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > 2. Since then I've been thinking/working on a cpu scheduler design
> > that takes away all the guesswork out of scheduling and gives very
> > predictable, as fair as
On Monday 16 April 2007 12:28, Nick Piggin wrote:
> So, on to something productive, we have 3 candidates for a new scheduler so
> far. How do we decide which way to go? (and yes, I still think switchable
> schedulers is wrong and a copout) This is one area where it is virtually
> impossible to
On Monday 16 April 2007 05:00, Jonathan Lundell wrote:
> On Apr 15, 2007, at 10:59 AM, Linus Torvalds wrote:
> > It's a really good thing, and it means that if somebody shows that
> > your
> > code is flawed in some way (by, for example, making a patch that
> > people
> > claim gets better
On Monday 16 April 2007 01:16, Gene Heskett wrote:
> On Sunday 15 April 2007, Pekka Enberg wrote:
> >On 4/15/07, hui Bill Huey <[EMAIL PROTECTED]> wrote:
> >> The perception here is that there is that there is this expectation that
> >> sections of the Linux kernel are intentionally "churn
On Monday 16 April 2007 05:00, Jonathan Lundell wrote:
On Apr 15, 2007, at 10:59 AM, Linus Torvalds wrote:
It's a really good thing, and it means that if somebody shows that
your
code is flawed in some way (by, for example, making a patch that
people
claim gets better behaviour or
On Monday 16 April 2007 12:28, Nick Piggin wrote:
So, on to something productive, we have 3 candidates for a new scheduler so
far. How do we decide which way to go? (and yes, I still think switchable
schedulers is wrong and a copout) This is one area where it is virtually
impossible to
On Monday 16 April 2007 01:05, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
2. Since then I've been thinking/working on a cpu scheduler design
that takes away all the guesswork out of scheduling and gives very
predictable, as fair as possible, cpu distribution and latency while
On Monday 16 April 2007 01:16, Gene Heskett wrote:
On Sunday 15 April 2007, Pekka Enberg wrote:
On 4/15/07, hui Bill Huey [EMAIL PROTECTED] wrote:
The perception here is that there is that there is this expectation that
sections of the Linux kernel are intentionally churn squated to
On Saturday 14 April 2007 06:21, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
> [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
>
On Saturday 14 April 2007 06:21, Ingo Molnar wrote:
[announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
[CFS]
i'm pleased to announce the first release of the Modular Scheduler Core
and Completely Fair Scheduler [CFS] patchset:
On Monday 09 April 2007 16:09, Andrew Morton wrote:
> On Sat, 07 Apr 2007 16:31:39 +0900 Satoru Takeuchi
<[EMAIL PROTECTED]> wrote:
> > When I was examining the following program ...
> >
> > 1. There are a large amount of small jobs takes several msecs,
> > and the number of job increases
Hi all
I'm alive and mostly well (yay!). I still should _not_ be spending extended
periods on the computer for my neck but this last change was I believe
essential and not too much effort.
Here's an update which should improve behaviour further with niced tasks.
tasks, and
simplifies greatly the code that generates the priority matrix.
Update the documentation accordingly and explain why the priority matrix
exists in the first place.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
Documentation/sched-design.txt | 13 +++--
kernel/s
tasks, and
simplifies greatly the code that generates the priority matrix.
Update the documentation accordingly and explain why the priority matrix
exists in the first place.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
---
Documentation/sched-design.txt | 13 +++--
kernel/sched.c
Hi all
I'm alive and mostly well (yay!). I still should _not_ be spending extended
periods on the computer for my neck but this last change was I believe
essential and not too much effort.
Here's an update which should improve behaviour further with niced tasks.
On Monday 09 April 2007 16:09, Andrew Morton wrote:
On Sat, 07 Apr 2007 16:31:39 +0900 Satoru Takeuchi
[EMAIL PROTECTED] wrote:
When I was examining the following program ...
1. There are a large amount of small jobs takes several msecs,
and the number of job increases constantly.
On Friday 06 April 2007 20:03, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > I was more focused on the general case, but all I should have to do
> > > to de-claw all of these sleep exploits is account rr time (only a
> > > couple of lines
On Friday 06 April 2007 20:03, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
I was more focused on the general case, but all I should have to do
to de-claw all of these sleep exploits is account rr time (only a
couple of lines, done and building now). It's only a couple
On Friday 06 April 2007 19:07, Mike Galbraith wrote:
> On Fri, 2007-04-06 at 11:03 +1000, Con Kolivas wrote:
> > On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
> > > - fiftyp.c: noticeable, but alot better than previously!
> >
> > fiftyp.c seems to have be
On Friday 06 April 2007 19:07, Mike Galbraith wrote:
On Fri, 2007-04-06 at 11:03 +1000, Con Kolivas wrote:
On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
- fiftyp.c: noticeable, but alot better than previously!
fiftyp.c seems to have been stumbled across by accident as having
On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
> - fiftyp.c: noticeable, but alot better than previously!
fiftyp.c seems to have been stumbled across by accident as having an effect
when Xenofon was trying to recreate Mike's 50% x 3 test case. I suggest a ten
percent version like the
On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-04-03 at 08:01 +0200, Ingo Molnar wrote:
> > > looks interesting - could you send the patch?
> >
> > Ok, this is looking/feeling pretty good in testing. Comments on
> > fugliness etc
On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
- fiftyp.c: noticeable, but alot better than previously!
fiftyp.c seems to have been stumbled across by accident as having an effect
when Xenofon was trying to recreate Mike's 50% x 3 test case. I suggest a ten
percent version like the
On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
On Tue, 2007-04-03 at 08:01 +0200, Ingo Molnar wrote:
looks interesting - could you send the patch?
Ok, this is looking/feeling pretty good in testing. Comments on
fugliness etc much
n just in case.
---
Use of memset 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 fil
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
201 - 300 of 1175 matches
Mail list logo
