Re: [RFC&PATCH] Alternative RCU implementation

Paul E. McKenney
2004-09-02T16:44:51Z

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