[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

aborting RPCs

From: Neal H. Walfield
Subject: aborting RPCs
Date: Wed, 10 Jan 2007 20:37:29 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 10 Jan 2007 18:50:37 +0100,
Tom Bachmann wrote:
> Neal H. Walfield schrieb:
> >> I don't think cpu time pools are to be passed to servers. Although this
> >> would increase accounting, it would as well horrify the complexity of
> >> the server and require special kernel support, as has been discussed on
> >> the list (or on coyotos-dev?).
> > 
> > I think they should.  Especially if we are to try and provide quality
> > of service guarantees and reduce cross talk.  [1] provides one possible 
> > model for this.
> > 
> >  [1] U. Steinberg, J. Wolter, H. Härtig: Fast Component Interaction
> >      for Real-Time Systems
> > 
> >      http://os.inf.tu-dresden.de/papers_ps/steinberg_ecrts2005.pdf
> > 
> As has been discussed on the list, the most complex problem is callers
> revoking donated time pools at arbitrary times. I don't think the paper
> pays appropriate account on this (at least not when considered as
> solving the general problem, which is not actually it's intent, iiuc.
> Also, the needed in-kernel mechanism has to traverse a potentially
> unbound number of process relationships [from time to time], which I
> think could be problematic, theoretically).

How to do this can be inferred from section 3.4: the revocation case
is similar to that when a thread exhausts its budget and there are
other waiting threads.  Another thread pushes the blocked thread
through on its own time.

After this is described, the authors then appear to mention a caveat:

  In a normal priority-based system threads always block on a thread
  with lower priority.  With reservations threads may also block on
  threads with higher priority and an expired capability reserve.  We
  have to adapt our donation algorithm to handle this situation.
  While parsing the dependency chain we may encounter a node with a
  higher prioirty and an expired capability reserve.  In this case the
  algorithm continues the dependecy traversal.

I'm having trouble understand the scenario and I've cc'd the primary
author who can hopefully give us a hint.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]