On Thu, Dec 13, 2007 at 07:52:41AM -0500, Steven Rostedt wrote:
>
>
> On Wed, 12 Dec 2007, Paul E. McKenney wrote:
>
> > >
> > > I'm pulling your patch for the above added code. Took me a few hours to
> > > find the culprit, but I was getting scheduling in atomic bugs. Turns out
> > > that this
On Wed, 12 Dec 2007, Paul E. McKenney wrote:
> >
> > I'm pulling your patch for the above added code. Took me a few hours to
> > find the culprit, but I was getting scheduling in atomic bugs. Turns out
> > that this code you put "preempt_disable" in calls sleeping spinlocks.
> >
> > Might want
On Wed, 12 Dec 2007, Paul E. McKenney wrote:
I'm pulling your patch for the above added code. Took me a few hours to
find the culprit, but I was getting scheduling in atomic bugs. Turns out
that this code you put preempt_disable in calls sleeping spinlocks.
Might want to run with
On Thu, Dec 13, 2007 at 07:52:41AM -0500, Steven Rostedt wrote:
On Wed, 12 Dec 2007, Paul E. McKenney wrote:
I'm pulling your patch for the above added code. Took me a few hours to
find the culprit, but I was getting scheduling in atomic bugs. Turns out
that this code you put
On Wed, Dec 12, 2007 at 10:56:12PM -0500, Steven Rostedt wrote:
>
> On Mon, 29 Oct 2007, Paul E. McKenney wrote:
> > diff -urpNa -X dontdiff linux-2.6.23.1-rt4/mm/memory.c
> > linux-2.6.23.1-rt4-fix/mm/memory.c
> > --- linux-2.6.23.1-rt4/mm/memory.c 2007-10-27 22:20:57.0 -0700
> > +++
On Mon, 29 Oct 2007, Paul E. McKenney wrote:
> diff -urpNa -X dontdiff linux-2.6.23.1-rt4/mm/memory.c
> linux-2.6.23.1-rt4-fix/mm/memory.c
> --- linux-2.6.23.1-rt4/mm/memory.c2007-10-27 22:20:57.0 -0700
> +++ linux-2.6.23.1-rt4-fix/mm/memory.c2007-10-28 15:40:36.0
>
On Mon, 29 Oct 2007, Paul E. McKenney wrote:
diff -urpNa -X dontdiff linux-2.6.23.1-rt4/mm/memory.c
linux-2.6.23.1-rt4-fix/mm/memory.c
--- linux-2.6.23.1-rt4/mm/memory.c2007-10-27 22:20:57.0 -0700
+++ linux-2.6.23.1-rt4-fix/mm/memory.c2007-10-28 15:40:36.0
-0700
On Wed, Dec 12, 2007 at 10:56:12PM -0500, Steven Rostedt wrote:
On Mon, 29 Oct 2007, Paul E. McKenney wrote:
diff -urpNa -X dontdiff linux-2.6.23.1-rt4/mm/memory.c
linux-2.6.23.1-rt4-fix/mm/memory.c
--- linux-2.6.23.1-rt4/mm/memory.c 2007-10-27 22:20:57.0 -0700
+++
On Thu, Nov 01, 2007 at 08:15:28AM +1100, Benjamin Herrenschmidt wrote:
>
> > So as Paul mentioned, spin_lock is now a mutex. There is a new
> > raw_spinlock however (simply change the way it is declared, calling
> > conventions are the same) which is used in a very few areas where a
> >
On Thu, Nov 01, 2007 at 08:15:28AM +1100, Benjamin Herrenschmidt wrote:
So as Paul mentioned, spin_lock is now a mutex. There is a new
raw_spinlock however (simply change the way it is declared, calling
conventions are the same) which is used in a very few areas where a
traditional
> So as Paul mentioned, spin_lock is now a mutex. There is a new
> raw_spinlock however (simply change the way it is declared, calling
> conventions are the same) which is used in a very few areas where a
> traditional spin_lock is truly necessary. This may or may not be one of
> those times,
On Tue, 2007-10-30 at 07:07 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2007-10-29 at 11:50 -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > A few random patches that permit POWER to pass kernbench on -rt.
> > Many of these have more focus on expediency than care for correctness,
> > so
On Tue, 2007-10-30 at 07:07 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2007-10-29 at 11:50 -0700, Paul E. McKenney wrote:
Hello!
A few random patches that permit POWER to pass kernbench on -rt.
Many of these have more focus on expediency than care for correctness,
so might best be
So as Paul mentioned, spin_lock is now a mutex. There is a new
raw_spinlock however (simply change the way it is declared, calling
conventions are the same) which is used in a very few areas where a
traditional spin_lock is truly necessary. This may or may not be one of
those times, but I
On Tue, Oct 30, 2007 at 07:37:50AM +1100, Benjamin Herrenschmidt wrote:
>
> On Mon, 2007-10-29 at 13:26 -0700, Paul E. McKenney wrote:
> >
> > > I see a lot of case where you add preempt_disable/enable around
> > areas
> > > that have the PTE lock held...
> > >
> > > So in -rt, spin_lock
On Mon, 2007-10-29 at 13:26 -0700, Paul E. McKenney wrote:
>
> > I see a lot of case where you add preempt_disable/enable around
> areas
> > that have the PTE lock held...
> >
> > So in -rt, spin_lock doesn't disable preempt ? I'm a bit worried...
> > there are some strong requirements that
On Tue, Oct 30, 2007 at 07:07:48AM +1100, Benjamin Herrenschmidt wrote:
>
> On Mon, 2007-10-29 at 11:50 -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > A few random patches that permit POWER to pass kernbench on -rt.
> > Many of these have more focus on expediency than care for correctness,
>
On Mon, 2007-10-29 at 11:50 -0700, Paul E. McKenney wrote:
> Hello!
>
> A few random patches that permit POWER to pass kernbench on -rt.
> Many of these have more focus on expediency than care for correctness,
> so might best be thought of as workarounds than as complete solutions.
> There are
Hello!
A few random patches that permit POWER to pass kernbench on -rt.
Many of these have more focus on expediency than care for correctness,
so might best be thought of as workarounds than as complete solutions.
There are still issues not addressed by this patch, including:
o
Hello!
A few random patches that permit POWER to pass kernbench on -rt.
Many of these have more focus on expediency than care for correctness,
so might best be thought of as workarounds than as complete solutions.
There are still issues not addressed by this patch, including:
o
On Mon, 2007-10-29 at 13:26 -0700, Paul E. McKenney wrote:
I see a lot of case where you add preempt_disable/enable around
areas
that have the PTE lock held...
So in -rt, spin_lock doesn't disable preempt ? I'm a bit worried...
there are some strong requirements that anything within
On Tue, Oct 30, 2007 at 07:07:48AM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2007-10-29 at 11:50 -0700, Paul E. McKenney wrote:
Hello!
A few random patches that permit POWER to pass kernbench on -rt.
Many of these have more focus on expediency than care for correctness,
so might
On Tue, Oct 30, 2007 at 07:37:50AM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2007-10-29 at 13:26 -0700, Paul E. McKenney wrote:
I see a lot of case where you add preempt_disable/enable around
areas
that have the PTE lock held...
So in -rt, spin_lock doesn't disable preempt
On Mon, 2007-10-29 at 11:50 -0700, Paul E. McKenney wrote:
Hello!
A few random patches that permit POWER to pass kernbench on -rt.
Many of these have more focus on expediency than care for correctness,
so might best be thought of as workarounds than as complete solutions.
There are still
24 matches
Mail list logo
