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 15, 2007 at 08
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
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
* 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!
* 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) {
> > -
* 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) {
- if
* 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've
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
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
with
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 15, 2007 at 08:14:52AM -0700, Paul E. McKenney wrote:
On Fri, Jun 15, 2007 at 04:45:35PM +0200, Ingo Molnar wrote:
Paul,
do
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
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 there in
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
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
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
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
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
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
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
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
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. McKenney
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 cooperate with
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
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, 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, 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 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
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 right.
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 to do,
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 does not
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) {
+
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
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.
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 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:
http://rt.wiki.kernel.org
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 more
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 see.
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 seen lot of them
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:
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
* 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
>-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'm running 2.6.21.4-rt12-cfs-v17
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 smooth.
One little thing, no
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 smooth.
One little thing, no
(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'm running 2.6.21.4-rt12-cfs-v17 (x86_64), so
-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.6.21.4-rt11
(Cc:-ed Venki
* 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
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 this -- thus
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:2770
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.
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
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
>
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
* 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
* 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 all
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 CPUs as I
* 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
the same
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
expect them to
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?
They start off
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 they start out with?
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. McKenney
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 can be found in the RT wiki:
>
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
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 think
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 can be found in the RT wiki:
75 matches
Mail list logo
