lkml.org 
[lkml]   [2006]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateWed, 21 Jun 2006 00:19:59 +0100 (BST)
SubjectRe: Why can't I set the priority of softirq-hrt? (Re: 2.6.17-rt1)
FromEsben Nielsen <>
On Tue, 20 Jun 2006, Thomas Gleixner wrote:

> On Tue, 2006-06-20 at 22:16 +0100, Esben Nielsen wrote:
>>> We had this before and it is horrible.
>>
>> "Horrible" in what respect?
>
> Unbound latencies.
>
>>> A nice solution would be to enqueue the timer into the task struct of
>>> the thread which is target of the signal, wake that thread in a special
>>> state which only runs the callback and then does the signal delivery.
>>
>> What if the thread is running?
>
> Well, do it in the return from interrupt path.

Wouldn't it just be the same as interrupt context then?

>
>> Hmm, a practical thing to do would be to make a system where you can post
>> jobs in a thread. These jobs can then be done in thread context
>> around schedule or just before the task returns to user-space.
>
> Thats basically what I said. But you have to take care of asynchronous
> signal delivery. Therefor you need a special state. Also return to
> userspace is not enough. You have to do the check in the return from
> interrupt path, as you might delay async signals otherwise.
>

It doesn't sound very preemptible then.

I was more thinking along the lines of having a "message" where threads
(and interrupts) can post functions to each other to be executed in
the target context.

The idea is:
1) You can get a fairly standeard code executeded with a priority
associated with the target thread.
2) Make sure that only one thread touches some data and that way avoid
having locks and therefore deadlocks.
3) Simplyfying callbacks. Instead of installing a callback which can be
executed in some task or interrupt, you can with this system make a
callback which will be executed in client's context, and thus simplyfying
the client's headaches with locks.

By "fairly standeard" code I mean code which doesn't block
except that it should be allowed to use mutexes, which in many ways is not
real blocking when PI is implemented.

If this should be safe you can't just preemp and execute these functions
anywhere in a thread. It must be in a well-defined place where no mutexes are
held. Many (all?) kernel threads have a while() with a central schedule() in
the middle. One can most often call these functions safely at this
schedule(). For userspace threads it would also be safe to call the functions
when going in and out of userspace. It will probably be safe to call the
functions at any call to schedule() except for the one inside the mutex
lock operation. The volentary-preemption points Ingo made some years ago
would probably be ok places, too.
Esben

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

\
 
 \ /
  Last update: 2006-06-21 00:22    [from the cache]
©2003-2010