On Tue, Jan 30, 2007 at 01:57:09PM -0800, Siddha, Suresh B wrote:
> Please let me know if you still see this issue with the latest -rt kernel.
>
> On Tue, Jan 16, 2007 at 12:35:05PM +0100, Ingo Molnar wrote:
> > on the latest -rt kernel, when the dynticks load-balancer is enabled,
> > then a
On Tue, Jan 30, 2007 at 01:57:09PM -0800, Siddha, Suresh B wrote:
Please let me know if you still see this issue with the latest -rt kernel.
On Tue, Jan 16, 2007 at 12:35:05PM +0100, Ingo Molnar wrote:
on the latest -rt kernel, when the dynticks load-balancer is enabled,
then a dual-core
Sorry for the delayed response. I was away on vacation.
Please let me know if you still see this issue with the latest -rt kernel.
thanks,
suresh
On Tue, Jan 16, 2007 at 12:35:05PM +0100, Ingo Molnar wrote:
>
> Suresh,
>
> on the latest -rt kernel, when the dynticks load-balancer is enabled,
Sorry for the delayed response. I was away on vacation.
Please let me know if you still see this issue with the latest -rt kernel.
thanks,
suresh
On Tue, Jan 16, 2007 at 12:35:05PM +0100, Ingo Molnar wrote:
Suresh,
on the latest -rt kernel, when the dynticks load-balancer is enabled,
Suresh,
on the latest -rt kernel, when the dynticks load-balancer is enabled,
then a dual-core Core2 Duo test-system increases its irq rate from the
normal 15/17 per second to 300-400/sec - on a completely idle system(!).
Any idea what's going on? I'll disable the load balancer for now.
Suresh,
on the latest -rt kernel, when the dynticks load-balancer is enabled,
then a dual-core Core2 Duo test-system increases its irq rate from the
normal 15/17 per second to 300-400/sec - on a completely idle system(!).
Any idea what's going on? I'll disable the load balancer for now.
On Mon, 2006-12-11 at 15:53 -0800, Siddha, Suresh B wrote:
>
> Comments and review feedback welcome. Minimal testing done on couple of
> i386 platforms. Perf testing yet to be done.
Nice work!
>
> thanks,
> suresh
> ---
> diff -pNru linux-2.6.19-mm1/include/linux/sched.h
On Tue, Dec 19, 2006 at 09:12:48PM +0100, Ingo Molnar wrote:
> restart:
> if (idle_cpu(local_cpu) && notick.load_balancer == local_cpu) {
> this_cpu = first_cpu(cpus);
> + if (unlikely(this_cpu >= NR_CPUS))
> + return;
oops.
There is window
find below another bugfix for the dynticks-sched patch. (this bug caused
crashed under a stresstest)
Ingo
---
kernel/sched.c |2 ++
1 file changed, 2 insertions(+)
Index: linux/kernel/sched.c
===
---
find below another bugfix for the dynticks-sched patch. (this bug caused
crashed under a stresstest)
Ingo
---
kernel/sched.c |2 ++
1 file changed, 2 insertions(+)
Index: linux/kernel/sched.c
===
---
On Tue, Dec 19, 2006 at 09:12:48PM +0100, Ingo Molnar wrote:
restart:
if (idle_cpu(local_cpu) notick.load_balancer == local_cpu) {
this_cpu = first_cpu(cpus);
+ if (unlikely(this_cpu = NR_CPUS))
+ return;
oops.
There is window when
On Mon, 2006-12-11 at 15:53 -0800, Siddha, Suresh B wrote:
Comments and review feedback welcome. Minimal testing done on couple of
i386 platforms. Perf testing yet to be done.
Nice work!
thanks,
suresh
---
diff -pNru linux-2.6.19-mm1/include/linux/sched.h linux/include/linux/sched.h
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > the other problem is load_balance(): there this_rq is locked and you
> > call resched_cpu() unconditionally.
>
> But here resched_cpu() was called after double_rq_unlock().
yeah, you are right - the schedule() one is/was the only problem.
On Thu, Dec 14, 2006 at 12:31:57AM +0100, Ingo Molnar wrote:
>
> * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Dec 14, 2006 at 12:13:16AM +0100, Ingo Molnar wrote:
> > > there's another bug as well: in schedule() resched_cpu() is called with
> > > the current runqueue held in two
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> The easiest fix for this is to use trylock - find the patch for that.
FYI, i have released 2.6.19-rt14 with your patch integrated into it as
well - it's looking good so far in my testing. (the yum repository will
be updated in a few minutes.)
On Thu, Dec 14, 2006 at 12:13:16AM +0100, Ingo Molnar wrote:
> there's another bug as well: in schedule() resched_cpu() is called with
> the current runqueue held in two places, which is deadlock potential.
resched_cpu() was getting called after prepare_task_switch() which
releases the current
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 14, 2006 at 12:13:16AM +0100, Ingo Molnar wrote:
> > there's another bug as well: in schedule() resched_cpu() is called with
> > the current runqueue held in two places, which is deadlock potential.
>
> resched_cpu() was getting
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Appended patch attempts to fix the process idle load balancing in
> > the presence of dynticks. cpus for which ticks are stopped will
> > sleep till the next event wakes it up. Potentially these sleeps can
> > be for large durations and during
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> Appended patch attempts to fix the process idle load balancing in the
> presence of dynticks. cpus for which ticks are stopped will sleep till
> the next event wakes it up. Potentially these sleeps can be for large
> durations and during which
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
Appended patch attempts to fix the process idle load balancing in the
presence of dynticks. cpus for which ticks are stopped will sleep till
the next event wakes it up. Potentially these sleeps can be for large
durations and during which today,
* Ingo Molnar [EMAIL PROTECTED] wrote:
Appended patch attempts to fix the process idle load balancing in
the presence of dynticks. cpus for which ticks are stopped will
sleep till the next event wakes it up. Potentially these sleeps can
be for large durations and during which today,
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
On Thu, Dec 14, 2006 at 12:13:16AM +0100, Ingo Molnar wrote:
there's another bug as well: in schedule() resched_cpu() is called with
the current runqueue held in two places, which is deadlock potential.
resched_cpu() was getting called after
On Thu, Dec 14, 2006 at 12:13:16AM +0100, Ingo Molnar wrote:
there's another bug as well: in schedule() resched_cpu() is called with
the current runqueue held in two places, which is deadlock potential.
resched_cpu() was getting called after prepare_task_switch() which
releases the current
* Ingo Molnar [EMAIL PROTECTED] wrote:
The easiest fix for this is to use trylock - find the patch for that.
FYI, i have released 2.6.19-rt14 with your patch integrated into it as
well - it's looking good so far in my testing. (the yum repository will
be updated in a few minutes.)
On Thu, Dec 14, 2006 at 12:31:57AM +0100, Ingo Molnar wrote:
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
On Thu, Dec 14, 2006 at 12:13:16AM +0100, Ingo Molnar wrote:
there's another bug as well: in schedule() resched_cpu() is called with
the current runqueue held in two places, which
* Siddha, Suresh B [EMAIL PROTECTED] wrote:
the other problem is load_balance(): there this_rq is locked and you
call resched_cpu() unconditionally.
But here resched_cpu() was called after double_rq_unlock().
yeah, you are right - the schedule() one is/was the only problem.
Appended patch attempts to fix the process idle load balancing in the
presence of dynticks. cpus for which ticks are stopped will sleep
till the next event wakes it up. Potentially these sleeps can be for large
durations and during which today, there is no idle load balancing being done.
There was
Appended patch attempts to fix the process idle load balancing in the
presence of dynticks. cpus for which ticks are stopped will sleep
till the next event wakes it up. Potentially these sleeps can be for large
durations and during which today, there is no idle load balancing being done.
There was
28 matches
Mail list logo
