Re: [RFC&PATCH] Alternative RCU implementation

[Paul E. McKenney]

On Wed, Sep 01, 2004 at 09:02:00AM -0400, Jim Houston wrote:
> On Tue, 2004-08-31 at 23:53, Paul E. McKenney wrote:
> > On Mon, Aug 30, 2004 at 11:22:49PM -0400, Jim Houston wrote:
> > > On Mon, 2004-08-30 at 14:52, Paul E. McKenney wrote: 
> > > > How does the rest of the kernel work with all interrupts to
> > > > a particular CPU shut off?  For example, how do you timeslice?
> > > 
> > > It's a balancing act.  In some cases we just document the
> > > missing functionality.  If the local timer is disabled on a cpu,
> > > all processes are SCHED_FIFO.  In the case of Posix timers, we
> > > move timers to honor the procesor shielding an the process affinity.
> > 
> > I have to ask...  When you say that you move the timers, you mean that
> > non-realtime CPU 1 managers timers for realtime CPU 0, so that CPU 1
> > is (effectively) taking CPU 0's timer interrupts?
> 
> Hi Paul,
> 
> That is part of the idea.  There are lots of timers which we don't
> expect to have realtime behavior.
> 
> There are also services like Posix timers and nanosleep() where we want
> very predictable behavior.  If a process does a nanosleep(), we queue
> that timer on the local cpu.  If process affinity is changed, we will
> move the timer to a cpu where the process is allowed to run.
> 
> We have separate queues for high resolution timers.  If the local queue
> is empty, we shutdown the timer.

Hello, Jim,

How do you mark a given CPU as being in realtime mode?  Or is the
timer-shutdown decision based on the presence of a realtime process
runnable on the given CPU or some such?

Still trying to figure out a way to make this work without adding
overhead to rcu_read_unlock()...

						Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/