Re: RFC: Unified kernel

Dmitriy Korovkin

On Mon, 30 May 2016, Stephens, Allan wrote:

Another thought occurred to me over the weekend. See [AL] below.

-- Al

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)]
Sent: May-26-16 4:11 PM
To: Kumar Gala
Cc: devel(a)
Subject: [devel] Re: RFC: Unified kernel

APIs needing special care

Some APIs need special treatment to make them function as they currently

Offload to fiber

Of course, a fiber is needed for this API. It is built on top of the
work_queue library. The system workqueue must be enabled.
[AL] Do we really need a fiber for this API? It seems we could get the same effect by temporarily "boosting" the priority of the invoking task to a negative value, calling the desired function, and then restoring the priority level to its original value. This would avoid the overhead of a double context switch, while still ensuring that the function isn't pre-empted by any task-type processing.

In essence, this API could be replaced by the sequence:

orig = task_priority_get();
task_priority_set(task_id_get(), -1);
<call function>
task_priority_set(task_id_get(), orig);

This being said, there is a potential issue if the function being invoked has the side effect of altering the priority of the invoking task (either explicitly or implicitly). If so, we would have to do something clever to ensure that things don't get messed up -- perhaps taking a similar approach to the one taken to handle priority inheritance with mutexes.

-- Al
Boosting priority of the invoking task may not be what we want to achieve.
In case of work_queue (correct me if I am wrong) we have an interrupt
handler that offloads the long work to the fiber for instance, taking data
from a temporary buffer and form a packet or so.


Join to automatically receive all group messages.