On Tue, 19 Jun 2007, Srivatsa Vaddagiri wrote:
> On Tue, Jun 19, 2007 at 11:04:30AM +0200, Ingo Molnar wrote:
> > I'm wondering, why did this trigger under CFS and not on mainline?
> > Mainline seems to have a similar problem in idle_balance() too, or am i
> > misreading it?
>
> The problem is
On Tue, 19 Jun 2007, Ingo Molnar wrote:
> I'm wondering, why did this trigger under CFS and not on mainline?
> Mainline seems to have a similar problem in idle_balance() too, or am i
> misreading it?
Right. The patch needs to go into mainline as well.
-
To unsubscribe from this list: send the
Date: Fri, 15 Jun 2007 13:06:17 -0700
From: "Paul E. McKenney" <[EMAIL PROTECTED]>
To: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>,
Dinakar Guniguntala <[EMAIL PROTECTED]>
Subject: Re: v2.6.21.4-rt11
On Fri, Jun
On Tue, Jun 19, 2007 at 11:04:30AM +0200, Ingo Molnar wrote:
> I'm wondering, why did this trigger under CFS and not on mainline?
> Mainline seems to have a similar problem in idle_balance() too, or am i
> misreading it?
The problem is there in mainline very much. I could recreate the problem
wi
On Tue, Jun 19, 2007 at 11:04:30AM +0200, Ingo Molnar wrote:
> I'm wondering, why did this trigger under CFS and not on mainline?
I thought Paul had seen the same problem with 2.6.21.5. I will try a
more recent mainline (2.6.22-rc5 maybe) after I get hold of the problem
machine and report later t
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> I believe the patch below is correct. With the patch applied, I could
> not recreate the imbalance with rcutorture. Let me know whether you
> still see the problem with this patch applied on any other machine.
thanks for tracking this down! I'v
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 18, 2007 at 08:46:03PM -0700, Christoph Lameter wrote:
> > @@ -2493,17 +2493,18 @@ static void idle_balance(int this_cpu, s
> > unsigned long next_balance = jiffies + 60 * HZ;
> >
> > for_each_domain(this_cpu, sd) {
> > -
On Mon, Jun 18, 2007 at 08:46:03PM -0700, Christoph Lameter wrote:
> @@ -2493,17 +2493,18 @@ static void idle_balance(int this_cpu, s
> unsigned long next_balance = jiffies + 60 * HZ;
>
> for_each_domain(this_cpu, sd) {
> - if (sd->flags & SD_BALANCE_NEWIDLE) {
> +
Katsuya-San,
On Tue, 2007-06-19 at 01:14 +0900, Katsuya MATSUBARA wrote:
> > It lacks support for the generic timeofday and clock event layers, which
> > causes the compile breakage.
>
> I am working on Renesas SuperH platforms.
> I faced the similar compile errors
> because 2.6.21.X in SH doe
On Mon, 18 Jun 2007, Siddha, Suresh B wrote:
> > + if (time_after(next_balance,
> > + sd->last_balance + sd->balance_interval))
> > + next_balance = sd->last_balance
> > + + sd->balance_interval;
>
> don't we have t
On Mon, Jun 18, 2007 at 10:59:21AM -0700, Christoph Lameter wrote:
> for_each_domain(this_cpu, sd) {
> - if (sd->flags & SD_BALANCE_NEWIDLE) {
> + if (sd->flags & SD_BALANCE_NEWIDLE)
> /* If we've pulled tasks over stop searching: */
>
On Tue, Jun 19, 2007 at 07:22:32AM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Jun 18, 2007 at 10:59:21AM -0700, Christoph Lameter wrote:
> > I think the check in idle_balance needs to be modified.
> >
> > If the domain *does not* have SD_BALANCE_NEWIDLE set then
> > next_balance must still be set
On Mon, Jun 18, 2007 at 10:59:21AM -0700, Christoph Lameter wrote:
> I think the check in idle_balance needs to be modified.
>
> If the domain *does not* have SD_BALANCE_NEWIDLE set then
> next_balance must still be set right. Does this patch fix it?
Is the ->next_balance calculation in idle_bala
On Mon, 18 Jun 2007, Srivatsa Vaddagiri wrote:
> On Mon, Jun 18, 2007 at 09:54:18AM -0700, Christoph Lameter wrote:
> > The nodes-level domain looks for internode balances between up to 16
> > nodes. It is not restricted to a single node.
>
> I was mostly speaking with the example system in mind
On Mon, Jun 18, 2007 at 08:42:15PM +0530, Srivatsa Vaddagiri wrote:
> If you don't have CONFIG_NUMA enabled,
> then we won't have cross-node (i.e cross-cpu) load balancing.
Mmm ..that is not correct. I found that disabling CONFIG_NUMA leads
to better load balance on the problem system (i.e w/o any
On Mon, Jun 18, 2007 at 09:54:18AM -0700, Christoph Lameter wrote:
> The nodes-level domain looks for internode balances between up to 16
> nodes. It is not restricted to a single node.
I was mostly speaking with the example system in mind (4-node 4-cpu
box), but yes, node-level domain does look
On Mon, 18 Jun 2007, Srivatsa Vaddagiri wrote:
> This particular machine, elm3b6, is a 4-cpu, (gasp, yes!) 4-node box i.e
> each CPU is a node by itself. If you don't have CONFIG_NUMA enabled,
> then we won't have cross-node (i.e cross-cpu) load balancing.
> Fortunately in your case you had CONFI
From: Thomas Gleixner <[EMAIL PROTECTED]>
Date: Sun, 17 Jun 2007 18:59:18 +0200
> On Sun, 2007-06-17 at 11:49 -0500, Nelson Castillo wrote:
> > > > There are many choices and
> > > > I don't know what is the more friendly. By friendly I mean the one that
> > > > is likely to be merged and that co
On Sat, Jun 16, 2007 at 09:12:13AM -0700, Paul E. McKenney wrote:
> On Sat, Jun 16, 2007 at 02:14:34PM +0530, Srivatsa Vaddagiri wrote:
> > On Fri, Jun 15, 2007 at 06:16:05PM -0700, Paul E. McKenney wrote:
> > > On Fri, Jun 15, 2007 at 09:55:45PM +0200, Ingo Molnar wrote:
> > > >
> > > > * Paul E.
On Sun, 2007-06-17 at 11:49 -0500, Nelson Castillo wrote:
> > > There are many choices and
> > > I don't know what is the more friendly. By friendly I mean the one that
> > > is likely to be merged and that cooperate with you.
> >
> > Which choices do you mean ?
>
> I mean implementations. I've se
On 6/17/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
On Sun, 2007-06-17 at 11:15 -0500, Nelson Castillo wrote:
> > http://rt.wiki.kernel.org
>
> Not for ARM yet :(
>
> What should I try for the ARM architecture?
ARM has a lot of sub architectures and not all of them are supported
yet.
I
On Sun, 2007-06-17 at 11:15 -0500, Nelson Castillo wrote:
> > http://rt.wiki.kernel.org
>
> Not for ARM yet :(
>
> What should I try for the ARM architecture?
ARM has a lot of sub architectures and not all of them are supported
yet.
> There are many choices and
> I don't know what is the
On 6/9/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
i'm pleased to announce the v2.6.21.4-rt11 kernel, which can be
downloaded from the usual place:
http://people.redhat.com/mingo/realtime-preempt/
more info about the -rt patchset can be found in the RT wiki:
On Tue, 2007-12-06 at 06:00 -0700, Pallipadi, Venkatesh wrote:
>
> >-Original Message-
> Yes. Force_hpet part is should have worked..
> Eric: Can you send me the output of 'lspci -n on your system.
> We need to double check we are covering all ICH7 ids.
Here it is:
00:00.0 0600: 8086:27
On Tue, Jun 12, 2007 at 11:37:58PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > Not a biggie for me, since I can easily do the taskset commands to
> > force the processes to spread out, but I am worried that casual users
> > of rcutorture won't know to do th
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> Not a biggie for me, since I can easily do the taskset commands to
> force the processes to spread out, but I am worried that casual users
> of rcutorture won't know to do this -- thus not really torturing RCU.
> It would not be hard to modify rc
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, June 12, 2007 12:32 AM
>To: Eric St-Laurent
>Cc: linux-kernel@vger.kernel.org;
>[EMAIL PROTECTED]; Thomas Gleixner; Dinakar
>Guniguntala; Pallipadi, Venkatesh
>Subject: Re: v2.
(Cc:-ed Venki for the force-hpet issue below)
* Eric St-Laurent <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-09-06 at 23:05 +0200, Ingo Molnar wrote:
> > i'm pleased to announce the v2.6.21.4-rt11 kernel, which can be
> > downloaded from the usual place:
>
> I
On Sat, 2007-09-06 at 23:05 +0200, Ingo Molnar wrote:
> i'm pleased to announce the v2.6.21.4-rt11 kernel, which can be
> downloaded from the usual place:
>
I'm running 2.6.21.4-rt12-cfs-v17 (x86_64), so far no problems. I like
this kernel a lot, it's feels quite smoot
On Mon, Jun 11, 2007 at 01:44:27PM -0700, Paul E. McKenney wrote:
> On Mon, Jun 11, 2007 at 10:18:06AM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 11, 2007 at 08:55:27AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jun 11, 2007 at 05:38:55PM +0200, Ingo Molnar wrote:
> > > >
> > > > * Paul E. M
On Mon, Jun 11, 2007 at 10:18:06AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 11, 2007 at 08:55:27AM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 11, 2007 at 05:38:55PM +0200, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> > >
> > > > > hm, what affinity do the
On Mon, Jun 11, 2007 at 08:55:27AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 11, 2007 at 05:38:55PM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> >
> > > > hm, what affinity do they start out with? Could they all be pinned
> > > > to CPU#0 by default?
> > >
On Mon, Jun 11, 2007 at 05:38:55PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > > hm, what affinity do they start out with? Could they all be pinned
> > > to CPU#0 by default?
> >
> > They start off with affinity masks of 0xf on a 4-CPU system. I would
> >
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> > hm, what affinity do they start out with? Could they all be pinned
> > to CPU#0 by default?
>
> They start off with affinity masks of 0xf on a 4-CPU system. I would
> expect them to load-balance across the four CPUs, but they stay all on
> th
On Mon, Jun 11, 2007 at 09:36:34AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > 2.6.21.4-rt12 boots on 4-CPU Opteron and passes several hours of
> > rcutorture. However, if I simply do "modprobe rcutorture", the kernel
> > threads do not spread across the C
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> 2.6.21.4-rt12 boots on 4-CPU Opteron and passes several hours of
> rcutorture. However, if I simply do "modprobe rcutorture", the kernel
> threads do not spread across the CPUs as I would expect them to, even
> given CFS. Instead, the readers a
On Sat, Jun 09, 2007 at 11:05:07PM +0200, Ingo Molnar wrote:
>
> i'm pleased to announce the v2.6.21.4-rt11 kernel, which can be
> downloaded from the usual place:
>
> http://people.redhat.com/mingo/realtime-preempt/
>
> more info about the -rt patchset c
On Sunday 10 June 2007 15:17, Ingo Molnar wrote:
> -rt11 is a bit more experimental than usual: it includes the CFS
> scheduler.
Great! Finally CFS is included ;)
Right now I'm using a patched kernel (2.6.21.4) with realtime-preemption patch
and it works fine but I noticed something that I thin
i'm pleased to announce the v2.6.21.4-rt11 kernel, which can be
downloaded from the usual place:
http://people.redhat.com/mingo/realtime-preempt/
more info about the -rt patchset can be found in the RT wiki:
http://rt.wiki.kernel.org
-rt11 is a bit more experimental
39 matches
Mail list logo
