[LITMUS^RT] Supporting Job Aborts

[Björn Brandenburg]

On 07.09.2012, at 21:05, Glenn Elliott <gelliott at cs.unc.edu> wrote:

> On Sep 7, 2012, at 2:57 PM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
>> On 07.09.2012, at 19:29, Jonathan Herman <hermanjl at cs.unc.edu> wrote:
>> 
>>> For Glenn's current issue, setitimer may give the correct result. I
>>> can imagine other situations where it wouldn't work. Suppose some kind
>>> of slack stealing is in effect, and the current task overexecutes, but
>>> this can be handled by the slack. We don't want the timer going off
>>> and having the task quit in this case.
>> 
>> In that case, I'd add a flag to mark the timer (or task) as "postponable on slack donation". Then the expiry time of the timer could be pushed back automatically on slack donation (and even advanced when, say, stealing budget from low-criticality tasks). 
> 
> I see how a task could push back its budget if it received extra time through stealing.  I suppose this information would have to be passed through control pages.  However, this still requires the application to handle the timer twice, right?  Steps: initial setup, original expiry{, reinitialization, revised expiry}*.  This seems a little less efficient, but it is a cleaner approach.  

No, I meant that the kernel modifies the timer directly in kernel space. It's essentially just a counter, which you could increase/decrease from the scheduling code with little overhead. It'll go off later / earlier as required. The manual resetting in userspace should be avoided in my opinion.


> I'm not sure how stealing works though.  How do we move the application-level budget timer forward in a remote process (the process we're stealing budget from)?  If there is a solution to do that, then we could use the same method to push timers back in others.

Presumably the scheduler transfers budget, not the the tasks themselves. Either way, you need kernel interaction. Just tweak the timer as described above when you are in kernelspace anyway.

- Björn