On Sat, 2005-02-19 at 15:45 -0500, Lee Revell wrote:
> On Sat, 2005-02-19 at 10:03 +0100, Ingo Molnar wrote:
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > > Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
> > > > latencies in the journalling code with
On Sat, 2005-02-19 at 15:45 -0500, Lee Revell wrote:
On Sat, 2005-02-19 at 10:03 +0100, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
On Wed, 2005-03-16 at 02:50 -0500, Steven Rostedt wrote:
>
> On Tue, 15 Mar 2005, Lee Revell wrote:
>
> > On Tue, 2005-03-15 at 13:05 -0500, Steven Rostedt wrote:
> > > Damn! The answer was right there in front of my eyes! Here's the cleanest
> > > solution. I forgot about wait_on_bit_lock.
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Damn! The answer was right there in front of my eyes! Here's the
> > cleanest solution. I forgot about wait_on_bit_lock. I've converted
> > all the locks to use this instead. [...]
>
> ah, indeed,
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Damn! The answer was right there in front of my eyes! Here's the
> cleanest solution. I forgot about wait_on_bit_lock. I've converted
> all the locks to use this instead. [...]
ah, indeed, this looks really nifty. Andrew?
Ingo
-
To
* Steven Rostedt [EMAIL PROTECTED] wrote:
Damn! The answer was right there in front of my eyes! Here's the
cleanest solution. I forgot about wait_on_bit_lock. I've converted
all the locks to use this instead. [...]
ah, indeed, this looks really nifty. Andrew?
Ingo
-
To unsubscribe
Ingo Molnar [EMAIL PROTECTED] wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Damn! The answer was right there in front of my eyes! Here's the
cleanest solution. I forgot about wait_on_bit_lock. I've converted
all the locks to use this instead. [...]
ah, indeed, this looks really
On Wed, 2005-03-16 at 02:50 -0500, Steven Rostedt wrote:
On Tue, 15 Mar 2005, Lee Revell wrote:
On Tue, 2005-03-15 at 13:05 -0500, Steven Rostedt wrote:
Damn! The answer was right there in front of my eyes! Here's the cleanest
solution. I forgot about wait_on_bit_lock. I've converted
On Tue, 15 Mar 2005, Lee Revell wrote:
> On Tue, 2005-03-15 at 13:05 -0500, Steven Rostedt wrote:
> > Damn! The answer was right there in front of my eyes! Here's the cleanest
> > solution. I forgot about wait_on_bit_lock. I've converted all the locks
> > to use this instead. We probably need
On Tue, 15 Mar 2005, Steven Rostedt wrote:
>
>
> On Tue, 15 Mar 2005, Ingo Molnar wrote:
> >
> > i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
> > would simplify things, besides making PREEMPT_RT simpler as well. The
> > memory overhead is not a big issue i believe.
On Tue, 2005-03-15 at 13:05 -0500, Steven Rostedt wrote:
> Damn! The answer was right there in front of my eyes! Here's the cleanest
> solution. I forgot about wait_on_bit_lock. I've converted all the locks
> to use this instead. We probably need to get priority inheritence working
> on this too
Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> The problem here is that it's not ext3 bh's only. They're still the normal
> buffer head. The problem arrises because the ext3 "journal head" is
> allocated within these bit spin locks.
Yes, the locks do want to live inside the buffer_head.
On Tue, 15 Mar 2005, Ingo Molnar wrote:
>
> i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
> would simplify things, besides making PREEMPT_RT simpler as well. The
> memory overhead is not a big issue i believe. (8 more bytes per ext3 bh,
> on x86)
>
Hi Ingo,
Damn! The
On Tue, 15 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
>
> > What should we use instead of #ifdef PREEMPT_RT? Or should we just
> > keep it the same for both. Since this fix is only to fix spinlocks
> > that schedule, I figured that it would be better not to
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > good progress - but the global lock may be a scalability worry on
> > upstream though. Would it be possible to just mirror much of the current
> > lock logic, but with spinlocks instead of bitlocks? And there should be
> > no #ifdefs on PREEMPT_RT.
On Tue, 15 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > I've realized that my previous patch had too many problems with the
> > way the journaling system works. So I went back to my first approach
> > but added the journal_head lock as one global lock to
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> I've realized that my previous patch had too many problems with the
> way the journaling system works. So I went back to my first approach
> but added the journal_head lock as one global lock to keep the buffer
> head size smaller. I only added the
I've realized that my previous patch had too many problems with the way
the journaling system works. So I went back to my first approach but
added the journal_head lock as one global lock to keep the buffer head
size smaller. I only added the state lock to the buffer head. I've tested
this for
I've realized that my previous patch had too many problems with the way
the journaling system works. So I went back to my first approach but
added the journal_head lock as one global lock to keep the buffer head
size smaller. I only added the state lock to the buffer head. I've tested
this for
* Steven Rostedt [EMAIL PROTECTED] wrote:
I've realized that my previous patch had too many problems with the
way the journaling system works. So I went back to my first approach
but added the journal_head lock as one global lock to keep the buffer
head size smaller. I only added the state
On Tue, 15 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
I've realized that my previous patch had too many problems with the
way the journaling system works. So I went back to my first approach
but added the journal_head lock as one global lock to keep the
* Steven Rostedt [EMAIL PROTECTED] wrote:
good progress - but the global lock may be a scalability worry on
upstream though. Would it be possible to just mirror much of the current
lock logic, but with spinlocks instead of bitlocks? And there should be
no #ifdefs on PREEMPT_RT.
The
On Tue, 15 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
What should we use instead of #ifdef PREEMPT_RT? Or should we just
keep it the same for both. Since this fix is only to fix spinlocks
that schedule, I figured that it would be better not to waste the
On Tue, 15 Mar 2005, Ingo Molnar wrote:
i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
would simplify things, besides making PREEMPT_RT simpler as well. The
memory overhead is not a big issue i believe. (8 more bytes per ext3 bh,
on x86)
Hi Ingo,
Damn! The
Steven Rostedt [EMAIL PROTECTED] wrote:
The problem here is that it's not ext3 bh's only. They're still the normal
buffer head. The problem arrises because the ext3 journal head is
allocated within these bit spin locks.
Yes, the locks do want to live inside the buffer_head.
Stephen has
On Tue, 2005-03-15 at 13:05 -0500, Steven Rostedt wrote:
Damn! The answer was right there in front of my eyes! Here's the cleanest
solution. I forgot about wait_on_bit_lock. I've converted all the locks
to use this instead. We probably need to get priority inheritence working
on this too
On Tue, 15 Mar 2005, Steven Rostedt wrote:
On Tue, 15 Mar 2005, Ingo Molnar wrote:
i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
would simplify things, besides making PREEMPT_RT simpler as well. The
memory overhead is not a big issue i believe. (8 more
On Tue, 15 Mar 2005, Lee Revell wrote:
On Tue, 2005-03-15 at 13:05 -0500, Steven Rostedt wrote:
Damn! The answer was right there in front of my eyes! Here's the cleanest
solution. I forgot about wait_on_bit_lock. I've converted all the locks
to use this instead. We probably need to get
Hi Ingo,
I've found something that is very interesting and I can't explain it.
On Mon, 14 Mar 2005, Steven Rostedt wrote:
>
>
> On Mon, 14 Mar 2005, Steven Rostedt wrote:
> >
> > On Mon, 14 Mar 2005, Steven Rostedt wrote:
> > >
> > > I just downloaded -40 and applied my patch, compiled it with
On Mon, 14 Mar 2005, Steven Rostedt wrote:
>
> On Mon, 14 Mar 2005, Steven Rostedt wrote:
> >
> > I just downloaded -40 and applied my patch, compiled it with
> > PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except
> > I'm getting the following...
> >
> > BUG: Unable to
On Mon, 14 Mar 2005, Steven Rostedt wrote:
>
> I just downloaded -40 and applied my patch, compiled it with
> PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except
> I'm getting the following...
>
> BUG: Unable to handle kernel NULL pointer dereference at virtual address
>
On Mon, 14 Mar 2005, Steven Rostedt wrote:
>
> > > I'll test this with PREEMPT_DESKTOP and data=ordered also and see how it
> > > goes.
> >
> > Does not seem to work at all with the above settings. It seemed OK
> > until I started X. Then every time I launched an xterm it would
> > disappear
On Mon, 14 Mar 2005, Steven Rostedt wrote:
I'll test this with PREEMPT_DESKTOP and data=ordered also and see how it
goes.
Does not seem to work at all with the above settings. It seemed OK
until I started X. Then every time I launched an xterm it would
disappear as soon as I
On Mon, 14 Mar 2005, Steven Rostedt wrote:
I just downloaded -40 and applied my patch, compiled it with
PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except
I'm getting the following...
BUG: Unable to handle kernel NULL pointer dereference at virtual address
On Mon, 14 Mar 2005, Steven Rostedt wrote:
On Mon, 14 Mar 2005, Steven Rostedt wrote:
I just downloaded -40 and applied my patch, compiled it with
PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except
I'm getting the following...
BUG: Unable to handle kernel NULL
Hi Ingo,
I've found something that is very interesting and I can't explain it.
On Mon, 14 Mar 2005, Steven Rostedt wrote:
On Mon, 14 Mar 2005, Steven Rostedt wrote:
On Mon, 14 Mar 2005, Steven Rostedt wrote:
I just downloaded -40 and applied my patch, compiled it with
On Fri, 11 Mar 2005, Lee Revell wrote:
> On Fri, 2005-03-11 at 15:46 -0500, Lee Revell wrote:
> > On Fri, 2005-03-11 at 15:39 -0500, Steven Rostedt wrote:
> > > I'm leaving now for the weekend, so I won't be able to respond to anyone
> > > till Monday. I'll also run this patch over the weekend
On Fri, 11 Mar 2005, Lee Revell wrote:
On Fri, 2005-03-11 at 15:46 -0500, Lee Revell wrote:
On Fri, 2005-03-11 at 15:39 -0500, Steven Rostedt wrote:
I'm leaving now for the weekend, so I won't be able to respond to anyone
till Monday. I'll also run this patch over the weekend while
On Fri, 2005-03-11 at 15:46 -0500, Lee Revell wrote:
> On Fri, 2005-03-11 at 15:39 -0500, Steven Rostedt wrote:
> > I'm leaving now for the weekend, so I won't be able to respond to anyone
> > till Monday. I'll also run this patch over the weekend while compiling
> > the kernel in an endless loop
On Fri, 2005-03-11 at 15:39 -0500, Steven Rostedt wrote:
> I'm leaving now for the weekend, so I won't be able to respond to anyone
> till Monday. I'll also run this patch over the weekend while compiling
> the kernel in an endless loop
I'll test this with PREEMPT_DESKTOP and data=ordered also
On Fri, 11 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Here's the patch. It's probably more of an overkill wrt buffer heads,
> > but it seems to be the easiest solution.
>
> isnt there some ext3-private journal structure (journal-bh) linked off
> the bh?
On Fri, 11 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Here's the patch. It's probably more of an overkill wrt buffer heads,
> > but it seems to be the easiest solution.
>
> isnt there some ext3-private journal structure (journal-bh) linked off
> the bh? If
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Here's the patch. It's probably more of an overkill wrt buffer heads,
> but it seems to be the easiest solution.
isnt there some ext3-private journal structure (journal-bh) linked off
the bh? If the lock is in that structure then the overhead would
Steven Rostedt wrote:
+#ifdef CONFIG_PREEMPT_RT
+#define PICK_SPIN_LOCK(otype,bit,name) spin_##otype(>b_##name##_lock)
+#else
+#define PICK_SPIN_LOCK(otype,bit,name) bit_spin_##otype(bit,bh->b_state);
+#endif
+
Oops, extra semicolon on the non RT side.
I'll try again.
-- Steve
Haven't tried it
>
> +#ifdef CONFIG_PREEMPT_RT
> +#define PICK_SPIN_LOCK(otype,bit,name) spin_##otype(>b_##name##_lock)
> +#else
> +#define PICK_SPIN_LOCK(otype,bit,name) bit_spin_##otype(bit,bh->b_state);
> +#endif
> +
Oops, extra semicolon on the non RT side.
I'll try again.
-- Steve
diff -ur
Here's the patch. It's probably more of an overkill wrt buffer heads, but
it seems to be the easiest solution.
I also put back some of the changes you made for the
bit_spin_locks, so that they act the same as the vanilla kernel if
PREEMPT_RT is not defined. Now I only tested this with
On Fri, 11 Mar 2005, Andrew Morton wrote:
> Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > No, I'll try that now. I just didn't want to modify the buffer head struct
> > just for journaling. But if it is the quickest and easiest fix, then I'll
> > submit it and we can change it later.
>
>
Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > did you try the canonical way of putting a spinlock into every
> > buffer_head?
> >
>
> No, I'll try that now. I just didn't want to modify the buffer head struct
> just for journaling. But if it is the quickest and easiest fix, then I'll
>
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > > Doing a quick search on the kernel, it looks like only kjournald uses
> > > the bit_spin_locks. I'll start converting them to spinlocks. The use
> > > seems to be more of a hack, since it is using bits in the state field
> > > for locking, and
On Fri, 11 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > > The short term fix is probably to put back the preempt_disables, the long
> > > term is to get rid of these stupid bit_spin_lock busy loops.
> >
> > Doing a quick search on the kernel, it looks like
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > The short term fix is probably to put back the preempt_disables, the long
> > term is to get rid of these stupid bit_spin_lock busy loops.
>
> Doing a quick search on the kernel, it looks like only kjournald uses
> the bit_spin_locks. I'll start
* Steven Rostedt [EMAIL PROTECTED] wrote:
The short term fix is probably to put back the preempt_disables, the long
term is to get rid of these stupid bit_spin_lock busy loops.
Doing a quick search on the kernel, it looks like only kjournald uses
the bit_spin_locks. I'll start converting
On Fri, 11 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
The short term fix is probably to put back the preempt_disables, the long
term is to get rid of these stupid bit_spin_lock busy loops.
Doing a quick search on the kernel, it looks like only kjournald
* Steven Rostedt [EMAIL PROTECTED] wrote:
Doing a quick search on the kernel, it looks like only kjournald uses
the bit_spin_locks. I'll start converting them to spinlocks. The use
seems to be more of a hack, since it is using bits in the state field
for locking, and these bits
Steven Rostedt [EMAIL PROTECTED] wrote:
did you try the canonical way of putting a spinlock into every
buffer_head?
No, I'll try that now. I just didn't want to modify the buffer head struct
just for journaling. But if it is the quickest and easiest fix, then I'll
submit it and
On Fri, 11 Mar 2005, Andrew Morton wrote:
Steven Rostedt [EMAIL PROTECTED] wrote:
No, I'll try that now. I just didn't want to modify the buffer head struct
just for journaling. But if it is the quickest and easiest fix, then I'll
submit it and we can change it later.
You'll need
Here's the patch. It's probably more of an overkill wrt buffer heads, but
it seems to be the easiest solution.
I also put back some of the changes you made for the
bit_spin_locks, so that they act the same as the vanilla kernel if
PREEMPT_RT is not defined. Now I only tested this with
+#ifdef CONFIG_PREEMPT_RT
+#define PICK_SPIN_LOCK(otype,bit,name) spin_##otype(bh-b_##name##_lock)
+#else
+#define PICK_SPIN_LOCK(otype,bit,name) bit_spin_##otype(bit,bh-b_state);
+#endif
+
Oops, extra semicolon on the non RT side.
I'll try again.
-- Steve
diff -ur
Steven Rostedt wrote:
+#ifdef CONFIG_PREEMPT_RT
+#define PICK_SPIN_LOCK(otype,bit,name) spin_##otype(bh-b_##name##_lock)
+#else
+#define PICK_SPIN_LOCK(otype,bit,name) bit_spin_##otype(bit,bh-b_state);
+#endif
+
Oops, extra semicolon on the non RT side.
I'll try again.
-- Steve
Haven't tried it
* Steven Rostedt [EMAIL PROTECTED] wrote:
Here's the patch. It's probably more of an overkill wrt buffer heads,
but it seems to be the easiest solution.
isnt there some ext3-private journal structure (journal-bh) linked off
the bh? If the lock is in that structure then the overhead would
On Fri, 11 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Here's the patch. It's probably more of an overkill wrt buffer heads,
but it seems to be the easiest solution.
isnt there some ext3-private journal structure (journal-bh) linked off
the bh? If the lock is
On Fri, 11 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Here's the patch. It's probably more of an overkill wrt buffer heads,
but it seems to be the easiest solution.
isnt there some ext3-private journal structure (journal-bh) linked off
the bh? If the lock
On Fri, 2005-03-11 at 15:39 -0500, Steven Rostedt wrote:
I'm leaving now for the weekend, so I won't be able to respond to anyone
till Monday. I'll also run this patch over the weekend while compiling
the kernel in an endless loop
I'll test this with PREEMPT_DESKTOP and data=ordered also and
On Fri, 2005-03-11 at 15:46 -0500, Lee Revell wrote:
On Fri, 2005-03-11 at 15:39 -0500, Steven Rostedt wrote:
I'm leaving now for the weekend, so I won't be able to respond to anyone
till Monday. I'll also run this patch over the weekend while compiling
the kernel in an endless loop
On Thu, 10 Mar 2005, Steven Rostedt wrote:
> The short term fix is probably to put back the preempt_disables, the long
> term is to get rid of these stupid bit_spin_lock busy loops.
>
Doing a quick search on the kernel, it looks like only kjournald uses the
bit_spin_locks. I'll start converting
Hi Ingo,
I notice a problem with the bit_spin_locks that would probably explain the
kjournald latency problems. I'm working on a custom kernel based on your's
and I needed to temporarily remove the scheduler_tick from
update_process_times to implement some special scheduling needs. This
caused
Hi Ingo,
I notice a problem with the bit_spin_locks that would probably explain the
kjournald latency problems. I'm working on a custom kernel based on your's
and I needed to temporarily remove the scheduler_tick from
update_process_times to implement some special scheduling needs. This
caused
On Thu, 10 Mar 2005, Steven Rostedt wrote:
The short term fix is probably to put back the preempt_disables, the long
term is to get rid of these stupid bit_spin_lock busy loops.
Doing a quick search on the kernel, it looks like only kjournald uses the
bit_spin_locks. I'll start converting
On Sat, 2005-02-19 at 10:03 +0100, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
> > > latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
> >
> > could you send me the full trace?
>
On
On Sat, 2005-02-19 at 10:03 +0100, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
could you send me the full trace?
On my other machine
On Sat, 2005-02-19 at 15:45 -0500, Lee Revell wrote:
> I have not tried "data=journal". As previously stated "data=writeback"
> works perfectly - I ran JACK overnight while stressing the fs and did
> not get one xrun.
"data=journal" has the same good performance as "data=writeback". Only
the
* Lee Revell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-02-04 at 11:03 +0100, Ingo Molnar wrote:
> > http://redhat.com/~mingo/realtime-preempt/
> >
>
> Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
> latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
> > latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
>
> could you send me the full trace?
just in case the system in question is still running - could you also do
* Ingo Molnar [EMAIL PROTECTED] wrote:
Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
could you send me the full trace?
just in case the system in question is still running - could you also do
a
* Lee Revell [EMAIL PROTECTED] wrote:
On Fri, 2005-02-04 at 11:03 +0100, Ingo Molnar wrote:
http://redhat.com/~mingo/realtime-preempt/
Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
could you
On Sat, 2005-02-19 at 15:45 -0500, Lee Revell wrote:
I have not tried data=journal. As previously stated data=writeback
works perfectly - I ran JACK overnight while stressing the fs and did
not get one xrun.
data=journal has the same good performance as data=writeback. Only
the ordered data
On Sat, 2005-02-19 at 00:08 -0500, Lee Revell wrote:
> On Fri, 2005-02-04 at 11:03 +0100, Ingo Molnar wrote:
> > http://redhat.com/~mingo/realtime-preempt/
> >
>
> Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
> latencies in the journalling code with
On Fri, 2005-02-04 at 11:03 +0100, Ingo Molnar wrote:
> http://redhat.com/~mingo/realtime-preempt/
>
Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
preemption latency trace v1.1.4 on
On Fri, 2005-02-04 at 11:03 +0100, Ingo Molnar wrote:
http://redhat.com/~mingo/realtime-preempt/
Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
preemption latency trace v1.1.4 on 2.6.11-rc4-RT-V0.7.39-02
On Sat, 2005-02-19 at 00:08 -0500, Lee Revell wrote:
On Fri, 2005-02-04 at 11:03 +0100, Ingo Molnar wrote:
http://redhat.com/~mingo/realtime-preempt/
Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.
On Sun, 2005-02-13 at 13:59 +0100, Ingo Molnar wrote:
> yeah - it's "M" already in fs/proc/array.c, but i missed the sched.c
> case.
>
You also missed the kernel/rt.c case :-)
-- Steve
Index: kernel/rt.c
===
--- kernel/rt.c
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> Here's a trivial patch to help others from freaking out when they see
> on a show_trace that most of their processes are TASK_UNINTERRUPTIBLE.
thanks, applied it to -39-00.
> - static const char *stat_nam[] = { "R", "S", "D", "T",
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
Here's a trivial patch to help others from freaking out when they see
on a show_trace that most of their processes are TASK_UNINTERRUPTIBLE.
thanks, applied it to -39-00.
- static const char *stat_nam[] = { R, S, D, T, t, Z, X };
+
On Sun, 2005-02-13 at 13:59 +0100, Ingo Molnar wrote:
yeah - it's M already in fs/proc/array.c, but i missed the sched.c
case.
You also missed the kernel/rt.c case :-)
-- Steve
Index: kernel/rt.c
===
--- kernel/rt.c (revision
Ingo,
Here's a trivial patch to help others from freaking out when they see on
a show_trace that most of their processes are TASK_UNINTERRUPTIBLE.
Index: kernel/sched.c
===
--- kernel/sched.c (revision 75)
+++ kernel/sched.c
* Sven Dietrich <[EMAIL PROTECTED]> wrote:
> > this patch only changes xtime_lock back and forth - it does
> > in no way impact the 'threadedness' of the timer IRQ. (it
> > does not move the timer IRQ into an interrupt thread.)
> >
> > nor do we really want to make it configurable - it's
> >
Ingo wrote:
>
> * Sven Dietrich <[EMAIL PROTECTED]> wrote:
>
> > This patch adds a config option to allow you to select
> whether timer
> > IRQ runs in thread or not.
>
> this patch only changes xtime_lock back and forth - it does
> in no way impact the 'threadedness' of the timer IRQ.
* Sven Dietrich <[EMAIL PROTECTED]> wrote:
> No, this is not in arm. Here is the patch.
>
> Index: linux-2.6.10/include/asm-i386/spinlock.h
what version do you have? The current released patch is
2.6.11-rc3-V0.7.38-10.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe
l.org
> Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
>
>
>
> * George Anzinger wrote:
>
> > Possibly from:
> > define __raw_spin_is_locked(x) (*(volatile signed char
> *)(&(x)->lock) <= 0)
> > #define __raw_spin_unlo
* George Anzinger wrote:
> Possibly from:
> define __raw_spin_is_locked(x)(*(volatile signed char *)(&(x)->lock)
> <= 0)
> #define __raw_spin_unlock_wait(x) \
> do { barrier(); } while(__spin_is_locked(x))
> in asm/spinlock.h
>
> should that be __raw_spin_is_locked(x) instead?
* Sven Dietrich <[EMAIL PROTECTED]> wrote:
> This patch adds a config option to allow you to select whether timer
> IRQ runs in thread or not.
this patch only changes xtime_lock back and forth - it does in no way
impact the 'threadedness' of the timer IRQ. (it does not move the timer
IRQ into
* Sven Dietrich [EMAIL PROTECTED] wrote:
This patch adds a config option to allow you to select whether timer
IRQ runs in thread or not.
this patch only changes xtime_lock back and forth - it does in no way
impact the 'threadedness' of the timer IRQ. (it does not move the timer
IRQ into an
* George Anzinger george@mvista.com wrote:
Possibly from:
define __raw_spin_is_locked(x)(*(volatile signed char *)((x)-lock)
= 0)
#define __raw_spin_unlock_wait(x) \
do { barrier(); } while(__spin_is_locked(x))
in asm/spinlock.h
should that be __raw_spin_is_locked(x)
spin_lock_string \
\n1:\t \
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ingo Molnar
Sent: Friday, February 11, 2005 12:34 AM
To: George Anzinger
Cc: William Weston; linux-kernel@vger.kernel.org
Subject: Re: [patch] Real-Time Preemption
* Sven Dietrich [EMAIL PROTECTED] wrote:
No, this is not in arm. Here is the patch.
Index: linux-2.6.10/include/asm-i386/spinlock.h
what version do you have? The current released patch is
2.6.11-rc3-V0.7.38-10.
Ingo
-
To unsubscribe from this list: send the line unsubscribe
Ingo wrote:
* Sven Dietrich [EMAIL PROTECTED] wrote:
This patch adds a config option to allow you to select
whether timer
IRQ runs in thread or not.
this patch only changes xtime_lock back and forth - it does
in no way impact the 'threadedness' of the timer IRQ. (it
does not
* Sven Dietrich [EMAIL PROTECTED] wrote:
this patch only changes xtime_lock back and forth - it does
in no way impact the 'threadedness' of the timer IRQ. (it
does not move the timer IRQ into an interrupt thread.)
nor do we really want to make it configurable - it's
non-threaded
Ingo,
Here's a trivial patch to help others from freaking out when they see on
a show_trace that most of their processes are TASK_UNINTERRUPTIBLE.
Index: kernel/sched.c
===
--- kernel/sched.c (revision 75)
+++ kernel/sched.c
Molnar
Cc: William Weston; linux-kernel@vger.kernel.org
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
If I want to write a patch that will work with or without the
RT patch applied
is the following enough?
#ifndef RAW_SPIN_LOCK_UNLOCKED
typedef raw_spinlock_t spinlock_t
[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> George Anzinger
> Sent: Thursday, February 10, 2005 12:21 PM
> To: Ingo Molnar
> Cc: William Weston; linux-kernel@vger.kernel.org
> Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
>
>
1 - 100 of 136 matches
Mail list logo
