[LITMUS^RT] Supporting Job Aborts

[Glenn Elliott]

On Sep 7, 2012, at 3:13 PM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> 
> 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

It sounds like the kernel still has to be modified to perform the budget changes.  How does the kernel know which timer instance associated with a task is the one that the task set up, at the application level, to perform the budget timing?  In all likelihood, there would just be one timer (especially just one with the ITIMER_VIRTUAL), but we still can't be entirely sure, right?

-Glenn