One Interrupted Threads per Interrupt line?

One Interrupted Threads per Interrupt line?

[Monica Puig-Pey]

Hi,

I'm using Ubuntu 10.04 with the 2.6.31-11-rt patch installed. I'm 
developing a PCI device driver using hardware interrupts.
I read in the “Internals of the RT Patch” document 
(http://www.kernel.org/doc/ols/2007/ols2007v2-pages-161-172.pdf ) that 
when a device driver requests an IRQ, a thread is created to service 
this interrupt line (Threaded interrupts). Only ONE thread can be 
created per interrupt line, so shared interrupts are still handled by a 
single thread.

My driver requests IRQ 16, which is shared with others handlers. Typing 
on the shell  $ps -eo pid,pri,rtprio,cmd I can see my driver requesting 
irq 16 and with 50 RTPRIO. At the same time I can see the others drivers 
requesting IRQ 16 with different real time priorities than mine( 80, 85, 
50). Does this mean that there are more than ONE Threaded Interrupts for 
IRQ 16? or it's just the thread priority when running each handler for 
IRQ 16?
Finally, how could I change the 50 RT PRIO for my handler pci_9111?

Here you have the shell:

   PID PRI RTPRIO CMD

   658 120     80 [irq/16-uhci_hcd]
  3852 125     85 [irq/16-HDA Inte]
  4303  90     50 [irq/16-radeon@p]
  5863  90     50 [irq/16-pci_9111]
  5865  19      - ps -eo pid,pri,rtprio,cmd


Thank you very much,

Mónica
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I/O operations priority in RTOS

[Monica Puig-Pey]

Hello,
I'm studying how to develop drivers in a real time OS and how do they 
work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
I would like to know the priority when executing open(), read(), write() 
and close() operations.
In my example the thread which is using the driver runs with 10 RTPRIO, 
but I don't know what happens in kernel context with the priority when 
running the I/O operations.
Thank you for your help, I don't know where to learn about this.

Mónica
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

kernel threads in drivers using the RT patch

[Monica Puig-Pey]

Hello,

I'm studying how to develop drivers in a real time OS and how do they 
work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
I'm trying to run a kernel thread from my driver (kernel context). I 
create the kthread in the module_init, I change its real time priority 
and then make it run .
Code shown below:

thread_handler=*(struct task_struct *)kthread_create(my_tasklet_handler, 
(void*)&datos,"thread_handler");
   if (IS_ERR(&thread_handler)){
      return PTR_ERR(&thread_handler);
      printk(KERN_WARNING "<pci> (init_module)  Error creating Thread 
handler\n");
   }
params->sched_priority=20;
result = sched_setscheduler(&thread_handler, SCHED_FIFO, params);
result=wake_up_process(&thread_handler);

Params is global struct sched_param * and struct thread_handler  a 
global task_struct.

I stop the Kthread in the module_exit using 
res=kthread_stop(&thread_handler);

The kthread "thread_handler" has a while (1) loop and it is stopped in a 
semaphore, waiting for the interrupt handler. When it wakes up each time 
it calls kthread_should_stop() and depending on that break out of the 
loop or run.

My problem is, when trying to establish the rtprio kthread, the whole 
computer get blocked and I only can restart it. If I delete this part, 
then kthread runs, and works well. With the ps command I can see it has 
a 24 NON real time priority. Then the problem come when uninstalling my 
module with rmmod. In the  kthread_stop function, everything gets blocked.

Could someone tell what am I doing wrong? Or just give me some help 
about kernel threads in the RT Patch?

Thanks a lot

Mónica
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Changing Kernel thread priorities

[Monica Puig-Pey]

I am writing a driver which has one kernel thread associated with it.
I want to change the priority of this thread, so that I can specify the 
order in which it is scheduled following an interrupt.
I'm using:

  sched_setscheduler(struct task_struct *, int, struct sched_param *);

but it doesn't work. I tried to change the priority from the 
init_module, and also from the Kernel Thread, but there is no way.

Kernel version is 2.6.31-11-rt

What do I call to change a kernel thread priority?

Thanks you very much

Mónica

Re: Changing Kernel thread priorities

[Rolando Martins]

Hi,
I use the following:

PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
print $1; }' | xargs echo)
for i in $PIDs
do
    ret=$(chrt -f -p 99 $i)
done

This will change the kernel thread associated with an irq handler to
RT FIFO prio 99.
Just change the script to your specific interrupt.

Hope it helps,
Rolando

On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey <puigpeym@unican.es> wrote:
> I am writing a driver which has one kernel thread associated with it.
> I want to change the priority of this thread, so that I can specify the
> order in which it is scheduled following an interrupt.
> I'm using:
>
>  sched_setscheduler(struct task_struct *, int, struct sched_param *);
>
> but it doesn't work. I tried to change the priority from the init_module,
> and also from the Kernel Thread, but there is no way.
>
> Kernel version is 2.6.31-11-rt
>
> What do I call to change a kernel thread priority?
>
> Thanks you very much
>
> Mónica
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Changing Kernel thread priorities

[Monica Puig-Pey]

El 06/06/11 13:54, Rolando Martins escribió:
> Hi,
> I use the following:
>
> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
> print $1; }' | xargs echo)
> for i in $PIDs
> do
>      ret=$(chrt -f -p 99 $i)
> done
>
> This will change the kernel thread associated with an irq handler to
> RT FIFO prio 99.
> Just change the script to your specific interrupt.
>
> Hope it helps,
> Rolando
>
> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>  wrote:
>> I am writing a driver which has one kernel thread associated with it.
>> I want to change the priority of this thread, so that I can specify the
>> order in which it is scheduled following an interrupt.
>> I'm using:
>>
>>   sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>
>> but it doesn't work. I tried to change the priority from the init_module,
>> and also from the Kernel Thread, but there is no way.
>>
>> Kernel version is 2.6.31-11-rt
>>
>> What do I call to change a kernel thread priority?
>>
>> Thanks you very much
>>
>> Mónica
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

I need to change the priority from inside the driver, when creating the 
kernel thread.
Your script is useful but it is done in user context,
Any other help please?

Mónica


--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Changing Kernel thread priorities

[Mark Hounschell]

On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
> El 06/06/11 13:54, Rolando Martins escribió:
>> Hi,
>> I use the following:
>>
>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>> print $1; }' | xargs echo)
>> for i in $PIDs
>> do
>> ret=$(chrt -f -p 99 $i)
>> done
>>
>> This will change the kernel thread associated with an irq handler to
>> RT FIFO prio 99.
>> Just change the script to your specific interrupt.
>>
>> Hope it helps,
>> Rolando
>>
>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>
>> wrote:
>>> I am writing a driver which has one kernel thread associated with it.
>>> I want to change the priority of this thread, so that I can specify the
>>> order in which it is scheduled following an interrupt.
>>> I'm using:
>>>
>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>
>>> but it doesn't work. I tried to change the priority from the
>>> init_module,
>>> and also from the Kernel Thread, but there is no way.
>>>
>>> Kernel version is 2.6.31-11-rt
>>>
>>> What do I call to change a kernel thread priority?
>>>
>>> Thanks you very much
>>>
>>> Mónica
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-rt-users" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
> I need to change the priority from inside the driver, when creating the
> kernel thread.
> Your script is useful but it is done in user context,
> Any other help please?

What I do is record the PID of the thread in the driver, then create an 
IOCTL for your driver that user land can call that either returns the 
PID so you can do it in user land, or cause the IOCTL code to do it in 
the driver.

The same can be done with the affinity of the IRQ if you record the IRQ 
number.

Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Changing Kernel thread priorities

[Monica Puig-Pey]

El 06/06/11 18:49, Mark Hounschell escribió:
> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>> El 06/06/11 13:54, Rolando Martins escribió:
>>> Hi,
>>> I use the following:
>>>
>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>> print $1; }' | xargs echo)
>>> for i in $PIDs
>>> do
>>> ret=$(chrt -f -p 99 $i)
>>> done
>>>
>>> This will change the kernel thread associated with an irq handler to
>>> RT FIFO prio 99.
>>> Just change the script to your specific interrupt.
>>>
>>> Hope it helps,
>>> Rolando
>>>
>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>
>>> wrote:
>>>> I am writing a driver which has one kernel thread associated with it.
>>>> I want to change the priority of this thread, so that I can specify the
>>>> order in which it is scheduled following an interrupt.
>>>> I'm using:
>>>>
>>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>>
>>>> but it doesn't work. I tried to change the priority from the
>>>> init_module,
>>>> and also from the Kernel Thread, but there is no way.
>>>>
>>>> Kernel version is 2.6.31-11-rt
>>>>
>>>> What do I call to change a kernel thread priority?
>>>>
>>>> Thanks you very much
>>>>
>>>> Mónica
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-rt-users" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>
>> I need to change the priority from inside the driver, when creating the
>> kernel thread.
>> Your script is useful but it is done in user context,
>> Any other help please?
>
> What I do is record the PID of the thread in the driver, then create an
> IOCTL for your driver that user land can call that either returns the
> PID so you can do it in user land, or cause the IOCTL code to do it in
> the driver.
>
> The same can be done with the affinity of the IRQ if you record the IRQ
> number.
>
> Mark
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

But I don't have de PID of my Kthread, I only have the task_struc * that 
gives me the function:

  struct task_struct *kthread_create(int (*threadfn)(void *data),
                    void *data,
                    const char namefmt[], ...)

How could I get the PID, and which function should I use in the IOCTL 
(kernel context) for changing its priority?

Thank you so much for your help

Mónica
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Changing Kernel thread priorities

[Mark Hounschell]

On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
> El 06/06/11 18:49, Mark Hounschell escribió:
>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>> Hi,
>>>> I use the following:
>>>>
>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>> print $1; }' | xargs echo)
>>>> for i in $PIDs
>>>> do
>>>> ret=$(chrt -f -p 99 $i)
>>>> done
>>>>
>>>> This will change the kernel thread associated with an irq handler to
>>>> RT FIFO prio 99.
>>>> Just change the script to your specific interrupt.
>>>>
>>>> Hope it helps,
>>>> Rolando
>>>>
>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>
>>>> wrote:
>>>>> I am writing a driver which has one kernel thread associated with it.
>>>>> I want to change the priority of this thread, so that I can specify the
>>>>> order in which it is scheduled following an interrupt.
>>>>> I'm using:
>>>>>
>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>>>
>>>>> but it doesn't work. I tried to change the priority from the
>>>>> init_module,
>>>>> and also from the Kernel Thread, but there is no way.
>>>>>
>>>>> Kernel version is 2.6.31-11-rt
>>>>>
>>>>> What do I call to change a kernel thread priority?
>>>>>
>>>>> Thanks you very much
>>>>>
>>>>> Mónica
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-rt-users" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>
>>> I need to change the priority from inside the driver, when creating the
>>> kernel thread.
>>> Your script is useful but it is done in user context,
>>> Any other help please?
>>
>> What I do is record the PID of the thread in the driver, then create an
>> IOCTL for your driver that user land can call that either returns the
>> PID so you can do it in user land, or cause the IOCTL code to do it in
>> the driver.
>>
>> The same can be done with the affinity of the IRQ if you record the IRQ
>> number.
>>
>> Mark
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-rt-users" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> But I don't have de PID of my Kthread, I only have the task_struc * that
> gives me the function:
>
> struct task_struct *kthread_create(int (*threadfn)(void *data),
> void *data,
> const char namefmt[], ...)
>
> How could I get the PID, and which function should I use in the IOCTL
> (kernel context) for changing its priority?
>

The PID can be obtained from within the interrupt handler its self via 
current->pid.
Obviously an interrupt has to occur first but after one interrupt you have it.

Actually I had forgot how I handled this. Where I change the RT priority 
and cpu affinity is in what used to be called the Bottom Half and the IOCTL 
referred to above simply tells the BH to do it and with what values.

Regards
Mark



--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Changing Kernel thread priorities

[Mark Hounschell]

On 06/07/2011 05:14 AM, Mark Hounschell wrote:
> On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
>> El 06/06/11 18:49, Mark Hounschell escribió:
>>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>>> Hi,
>>>>> I use the following:
>>>>>
>>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>>> print $1; }' | xargs echo)
>>>>> for i in $PIDs
>>>>> do
>>>>> ret=$(chrt -f -p 99 $i)
>>>>> done
>>>>>
>>>>> This will change the kernel thread associated with an irq handler to
>>>>> RT FIFO prio 99.
>>>>> Just change the script to your specific interrupt.
>>>>>
>>>>> Hope it helps,
>>>>> Rolando
>>>>>
>>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>
>>>>> wrote:
>>>>>> I am writing a driver which has one kernel thread associated with it.
>>>>>> I want to change the priority of this thread, so that I can specify the
>>>>>> order in which it is scheduled following an interrupt.
>>>>>> I'm using:
>>>>>>
>>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>>>>
>>>>>> but it doesn't work. I tried to change the priority from the
>>>>>> init_module,
>>>>>> and also from the Kernel Thread, but there is no way.
>>>>>>
>>>>>> Kernel version is 2.6.31-11-rt
>>>>>>
>>>>>> What do I call to change a kernel thread priority?
>>>>>>
>>>>>> Thanks you very much
>>>>>>
>>>>>> Mónica
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> linux-rt-users" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>
>>>> I need to change the priority from inside the driver, when creating the
>>>> kernel thread.
>>>> Your script is useful but it is done in user context,
>>>> Any other help please?
>>>
>>> What I do is record the PID of the thread in the driver, then create an
>>> IOCTL for your driver that user land can call that either returns the
>>> PID so you can do it in user land, or cause the IOCTL code to do it in
>>> the driver.
>>>
>>> The same can be done with the affinity of the IRQ if you record the IRQ
>>> number.
>>>
>>> Mark
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-rt-users" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> But I don't have de PID of my Kthread, I only have the task_struc * that
>> gives me the function:
>>
>> struct task_struct *kthread_create(int (*threadfn)(void *data),
>> void *data,
>> const char namefmt[], ...)
>>
>> How could I get the PID, and which function should I use in the IOCTL
>> (kernel context) for changing its priority?
>>
>
> The PID can be obtained from within the interrupt handler its self via
> current->pid.
> Obviously an interrupt has to occur first but after one interrupt you have it.
>
> Actually I had forgot how I handled this. Where I change the RT priority
> and cpu affinity is in what used to be called the Bottom Half and the IOCTL
> referred to above simply tells the BH to do it and with what values.
>

In interrupt handler code snippet:

struct task_struct *TSK;
struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };

         TSK = current;

Code snippet from BH:

         if (((rtom_rtprio != 0) &&
              (rtom_rtprio != PARAM.sched_priority)) ||
              (my_rtom_rtprio[BOARD] != rtom_rtprio)) {

                 PARAM.sched_priority = rtom_rtprio;
                 my_rtom_rtprio[COUNT] = rtom_rtprio;
                 sched_setscheduler(TSK, SCHED_FIFO, &PARAM);

                 set_cpus_allowed(TSK, rtom_devices[BOARD].irq_cpu_mask);
                 rtom_devices[BOARD].irq_task_pid = TSK->pid;
        }

rtom_rtprio and irq_cpu_mask are set by userland via an IOCTL. An interrupt 
must occur for this to happen and my BOARD never shares IRQs.

Mark

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Changing Kernel thread priorities

[Monica Puig-Pey]

El 07/06/11 11:46, Mark Hounschell escribió:
> On 06/07/2011 05:14 AM, Mark Hounschell wrote:
>> On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
>>> El 06/06/11 18:49, Mark Hounschell escribió:
>>>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>>>> Hi,
>>>>>> I use the following:
>>>>>>
>>>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>>>> print $1; }' | xargs echo)
>>>>>> for i in $PIDs
>>>>>> do
>>>>>> ret=$(chrt -f -p 99 $i)
>>>>>> done
>>>>>>
>>>>>> This will change the kernel thread associated with an irq handler to
>>>>>> RT FIFO prio 99.
>>>>>> Just change the script to your specific interrupt.
>>>>>>
>>>>>> Hope it helps,
>>>>>> Rolando
>>>>>>
>>>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey
>>>>>> wrote:
>>>>>>> I am writing a driver which has one kernel thread associated with
>>>>>>> it.
>>>>>>> I want to change the priority of this thread, so that I can
>>>>>>> specify the
>>>>>>> order in which it is scheduled following an interrupt.
>>>>>>> I'm using:
>>>>>>>
>>>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>>>>>
>>>>>>> but it doesn't work. I tried to change the priority from the
>>>>>>> init_module,
>>>>>>> and also from the Kernel Thread, but there is no way.
>>>>>>>
>>>>>>> Kernel version is 2.6.31-11-rt
>>>>>>>
>>>>>>> What do I call to change a kernel thread priority?
>>>>>>>
>>>>>>> Thanks you very much
>>>>>>>
>>>>>>> Mónica
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>> linux-rt-users" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>
>>>>>
>>>>> I need to change the priority from inside the driver, when creating
>>>>> the
>>>>> kernel thread.
>>>>> Your script is useful but it is done in user context,
>>>>> Any other help please?
>>>>
>>>> What I do is record the PID of the thread in the driver, then create an
>>>> IOCTL for your driver that user land can call that either returns the
>>>> PID so you can do it in user land, or cause the IOCTL code to do it in
>>>> the driver.
>>>>
>>>> The same can be done with the affinity of the IRQ if you record the IRQ
>>>> number.
>>>>
>>>> Mark
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-rt-users" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> But I don't have de PID of my Kthread, I only have the task_struc * that
>>> gives me the function:
>>>
>>> struct task_struct *kthread_create(int (*threadfn)(void *data),
>>> void *data,
>>> const char namefmt[], ...)
>>>
>>> How could I get the PID, and which function should I use in the IOCTL
>>> (kernel context) for changing its priority?
>>>
>>
>> The PID can be obtained from within the interrupt handler its self via
>> current->pid.
>> Obviously an interrupt has to occur first but after one interrupt you
>> have it.
>>
>> Actually I had forgot how I handled this. Where I change the RT priority
>> and cpu affinity is in what used to be called the Bottom Half and the
>> IOCTL
>> referred to above simply tells the BH to do it and with what values.
>>
>
> In interrupt handler code snippet:
>
> struct task_struct *TSK;
> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
>
> TSK = current;
>
> Code snippet from BH:
>
> if (((rtom_rtprio != 0) &&
> (rtom_rtprio != PARAM.sched_priority)) ||
> (my_rtom_rtprio[BOARD] != rtom_rtprio)) {
>
> PARAM.sched_priority = rtom_rtprio;
> my_rtom_rtprio[COUNT] = rtom_rtprio;
> sched_setscheduler(TSK, SCHED_FIFO, &PARAM);
>
> set_cpus_allowed(TSK, rtom_devices[BOARD].irq_cpu_mask);
> rtom_devices[BOARD].irq_task_pid = TSK->pid;
> }
>
> rtom_rtprio and irq_cpu_mask are set by userland via an IOCTL. An
> interrupt must occur for this to happen and my BOARD never shares IRQs.
>
> Mark
>

Thanks, your idea seems to be very useful to me. I was doing it very 
similar, but I didn't use the "current" variable to know the task_struct *.

I have tried your suggestion on an easy example, but it didn't work.
Insmod returns through the kernel

	[11334.895499] kthread: Unknown symbol sched_setscheduler

Code shown below:

#include <linux/module.h>	
#include <linux/kernel.h>
#include <linux/ioport.h>

#include <linux/wait.h>
#include <linux/kthread.h>
#include <asm/io.h>
#include <linux/sched.h>


struct task_struct *ts;

int thread(void *data)
{
   struct task_struct *TSK;
   struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
   TSK = current;

   PARAM.sched_priority = 50;
   sched_setscheduler(TSK, SCHED_FIFO, &PARAM); // <-- unknown symbol??

   while(1){
     printk("Hi I am kernel thread!\n");
     msleep(100);
     if (kthread_should_stop())
       break;		
}
         return 0;
}


int init_module(void)
{
   printk(KERN_INFO "init_module() called\n");
   ts=kthread_run(thread,NULL,"kthread");
          return 0;
}

void cleanup_module(void)
{
   printk(KERN_INFO "cleanup_module() called\n");
   kthread_stop(ts);
}

Re: Changing Kernel thread priorities

[Mark Hounschell]

On 06/07/2011 02:34 PM, Monica Puig-Pey wrote:
> El 07/06/11 11:46, Mark Hounschell escribió:
>> On 06/07/2011 05:14 AM, Mark Hounschell wrote:
>>> On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
>>>> El 06/06/11 18:49, Mark Hounschell escribió:
>>>>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>>>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>>>>> Hi,
>>>>>>> I use the following:
>>>>>>>
>>>>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>>>>> print $1; }' | xargs echo)
>>>>>>> for i in $PIDs
>>>>>>> do
>>>>>>> ret=$(chrt -f -p 99 $i)
>>>>>>> done
>>>>>>>
>>>>>>> This will change the kernel thread associated with an irq handler to
>>>>>>> RT FIFO prio 99.
>>>>>>> Just change the script to your specific interrupt.
>>>>>>>
>>>>>>> Hope it helps,
>>>>>>> Rolando
>>>>>>>
>>>>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey
>>>>>>> wrote:
>>>>>>>> I am writing a driver which has one kernel thread associated with
>>>>>>>> it.
>>>>>>>> I want to change the priority of this thread, so that I can
>>>>>>>> specify the
>>>>>>>> order in which it is scheduled following an interrupt.
>>>>>>>> I'm using:
>>>>>>>>
>>>>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param
>>>>>>>> *);
>>>>>>>>
>>>>>>>> but it doesn't work. I tried to change the priority from the
>>>>>>>> init_module,
>>>>>>>> and also from the Kernel Thread, but there is no way.
>>>>>>>>
>>>>>>>> Kernel version is 2.6.31-11-rt
>>>>>>>>
>>>>>>>> What do I call to change a kernel thread priority?
>>>>>>>>
>>>>>>>> Thanks you very much
>>>>>>>>
>>>>>>>> Mónica
>>>>>>>>
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>> linux-rt-users" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>
>>>>>>
>>>>>> I need to change the priority from inside the driver, when creating
>>>>>> the
>>>>>> kernel thread.
>>>>>> Your script is useful but it is done in user context,
>>>>>> Any other help please?
>>>>>
>>>>> What I do is record the PID of the thread in the driver, then
>>>>> create an
>>>>> IOCTL for your driver that user land can call that either returns the
>>>>> PID so you can do it in user land, or cause the IOCTL code to do it in
>>>>> the driver.
>>>>>
>>>>> The same can be done with the affinity of the IRQ if you record the
>>>>> IRQ
>>>>> number.
>>>>>
>>>>> Mark
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-rt-users" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>> But I don't have de PID of my Kthread, I only have the task_struc *
>>>> that
>>>> gives me the function:
>>>>
>>>> struct task_struct *kthread_create(int (*threadfn)(void *data),
>>>> void *data,
>>>> const char namefmt[], ...)
>>>>
>>>> How could I get the PID, and which function should I use in the IOCTL
>>>> (kernel context) for changing its priority?
>>>>
>>>
>>> The PID can be obtained from within the interrupt handler its self via
>>> current->pid.
>>> Obviously an interrupt has to occur first but after one interrupt you
>>> have it.
>>>
>>> Actually I had forgot how I handled this. Where I change the RT priority
>>> and cpu affinity is in what used to be called the Bottom Half and the
>>> IOCTL
>>> referred to above simply tells the BH to do it and with what values.
>>>
>>
>> In interrupt handler code snippet:
>>
>> struct task_struct *TSK;
>> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
>>
>> TSK = current;
>>
>> Code snippet from BH:
>>
>> if (((rtom_rtprio != 0) &&
>> (rtom_rtprio != PARAM.sched_priority)) ||
>> (my_rtom_rtprio[BOARD] != rtom_rtprio)) {
>>
>> PARAM.sched_priority = rtom_rtprio;
>> my_rtom_rtprio[COUNT] = rtom_rtprio;
>> sched_setscheduler(TSK, SCHED_FIFO, &PARAM);
>>
>> set_cpus_allowed(TSK, rtom_devices[BOARD].irq_cpu_mask);
>> rtom_devices[BOARD].irq_task_pid = TSK->pid;
>> }
>>
>> rtom_rtprio and irq_cpu_mask are set by userland via an IOCTL. An
>> interrupt must occur for this to happen and my BOARD never shares IRQs.
>>
>> Mark
>>
>
> Thanks, your idea seems to be very useful to me. I was doing it very
> similar, but I didn't use the "current" variable to know the task_struct *.
>
> I have tried your suggestion on an easy example, but it didn't work.
> Insmod returns through the kernel
>
> [11334.895499] kthread: Unknown symbol sched_setscheduler
>
> Code shown below:
>
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/ioport.h>
>
> #include <linux/wait.h>
> #include <linux/kthread.h>
> #include <asm/io.h>
> #include <linux/sched.h>
>
>
> struct task_struct *ts;
>
> int thread(void *data)
> {
> struct task_struct *TSK;
> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
> TSK = current;
>
> PARAM.sched_priority = 50;
> sched_setscheduler(TSK, SCHED_FIFO, &PARAM); // <-- unknown symbol??
>
> while(1){
> printk("Hi I am kernel thread!\n");
> msleep(100);
> if (kthread_should_stop())
> break;
> }
> return 0;
> }
>
>
> int init_module(void)
> {
> printk(KERN_INFO "init_module() called\n");
> ts=kthread_run(thread,NULL,"kthread");
> return 0;
> }
>
> void cleanup_module(void)
> {
> printk(KERN_INFO "cleanup_module() called\n");
> kthread_stop(ts);
> }
> .
>

In kernel/sched.c

EXPORT_SYMBOL_GPL(sched_setscheduler);

If your driver is not GPL, you can't use it.

Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Changing Kernel thread priorities

[Monica Puig-Pey]

El 07/06/11 20:55, Mark Hounschell escribió:
> On 06/07/2011 02:34 PM, Monica Puig-Pey wrote:
>> El 07/06/11 11:46, Mark Hounschell escribió:
>>> On 06/07/2011 05:14 AM, Mark Hounschell wrote:
>>>> On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
>>>>> El 06/06/11 18:49, Mark Hounschell escribió:
>>>>>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>>>>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>>>>>> Hi,
>>>>>>>> I use the following:
>>>>>>>>
>>>>>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>>>>>> print $1; }' | xargs echo)
>>>>>>>> for i in $PIDs
>>>>>>>> do
>>>>>>>> ret=$(chrt -f -p 99 $i)
>>>>>>>> done
>>>>>>>>
>>>>>>>> This will change the kernel thread associated with an irq
>>>>>>>> handler to
>>>>>>>> RT FIFO prio 99.
>>>>>>>> Just change the script to your specific interrupt.
>>>>>>>>
>>>>>>>> Hope it helps,
>>>>>>>> Rolando
>>>>>>>>
>>>>>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey
>>>>>>>> wrote:
>>>>>>>>> I am writing a driver which has one kernel thread associated with
>>>>>>>>> it.
>>>>>>>>> I want to change the priority of this thread, so that I can
>>>>>>>>> specify the
>>>>>>>>> order in which it is scheduled following an interrupt.
>>>>>>>>> I'm using:
>>>>>>>>>
>>>>>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param
>>>>>>>>> *);
>>>>>>>>>
>>>>>>>>> but it doesn't work. I tried to change the priority from the
>>>>>>>>> init_module,
>>>>>>>>> and also from the Kernel Thread, but there is no way.
>>>>>>>>>
>>>>>>>>> Kernel version is 2.6.31-11-rt
>>>>>>>>>
>>>>>>>>> What do I call to change a kernel thread priority?
>>>>>>>>>
>>>>>>>>> Thanks you very much
>>>>>>>>>
>>>>>>>>> Mónica
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>> linux-rt-users" in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>
>>>>>>>
>>>>>>> I need to change the priority from inside the driver, when creating
>>>>>>> the
>>>>>>> kernel thread.
>>>>>>> Your script is useful but it is done in user context,
>>>>>>> Any other help please?
>>>>>>
>>>>>> What I do is record the PID of the thread in the driver, then
>>>>>> create an
>>>>>> IOCTL for your driver that user land can call that either returns the
>>>>>> PID so you can do it in user land, or cause the IOCTL code to do
>>>>>> it in
>>>>>> the driver.
>>>>>>
>>>>>> The same can be done with the affinity of the IRQ if you record the
>>>>>> IRQ
>>>>>> number.
>>>>>>
>>>>>> Mark
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> linux-rt-users" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>> But I don't have de PID of my Kthread, I only have the task_struc *
>>>>> that
>>>>> gives me the function:
>>>>>
>>>>> struct task_struct *kthread_create(int (*threadfn)(void *data),
>>>>> void *data,
>>>>> const char namefmt[], ...)
>>>>>
>>>>> How could I get the PID, and which function should I use in the IOCTL
>>>>> (kernel context) for changing its priority?
>>>>>
>>>>
>>>> The PID can be obtained from within the interrupt handler its self via
>>>> current->pid.
>>>> Obviously an interrupt has to occur first but after one interrupt you
>>>> have it.
>>>>
>>>> Actually I had forgot how I handled this. Where I change the RT
>>>> priority
>>>> and cpu affinity is in what used to be called the Bottom Half and the
>>>> IOCTL
>>>> referred to above simply tells the BH to do it and with what values.
>>>>
>>>
>>> In interrupt handler code snippet:
>>>
>>> struct task_struct *TSK;
>>> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
>>>
>>> TSK = current;
>>>
>>> Code snippet from BH:
>>>
>>> if (((rtom_rtprio != 0) &&
>>> (rtom_rtprio != PARAM.sched_priority)) ||
>>> (my_rtom_rtprio[BOARD] != rtom_rtprio)) {
>>>
>>> PARAM.sched_priority = rtom_rtprio;
>>> my_rtom_rtprio[COUNT] = rtom_rtprio;
>>> sched_setscheduler(TSK, SCHED_FIFO, &PARAM);
>>>
>>> set_cpus_allowed(TSK, rtom_devices[BOARD].irq_cpu_mask);
>>> rtom_devices[BOARD].irq_task_pid = TSK->pid;
>>> }
>>>
>>> rtom_rtprio and irq_cpu_mask are set by userland via an IOCTL. An
>>> interrupt must occur for this to happen and my BOARD never shares IRQs.
>>>
>>> Mark
>>>
>>
>> Thanks, your idea seems to be very useful to me. I was doing it very
>> similar, but I didn't use the "current" variable to know the
>> task_struct *.
>>
>> I have tried your suggestion on an easy example, but it didn't work.
>> Insmod returns through the kernel
>>
>> [11334.895499] kthread: Unknown symbol sched_setscheduler
>>
>> Code shown below:
>>
>> #include <linux/module.h>
>> #include <linux/kernel.h>
>> #include <linux/ioport.h>
>>
>> #include <linux/wait.h>
>> #include <linux/kthread.h>
>> #include <asm/io.h>
>> #include <linux/sched.h>
>>
>>
>> struct task_struct *ts;
>>
>> int thread(void *data)
>> {
>> struct task_struct *TSK;
>> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
>> TSK = current;
>>
>> PARAM.sched_priority = 50;
>> sched_setscheduler(TSK, SCHED_FIFO, &PARAM); // <-- unknown symbol??
>>
>> while(1){
>> printk("Hi I am kernel thread!\n");
>> msleep(100);
>> if (kthread_should_stop())
>> break;
>> }
>> return 0;
>> }
>>
>>
>> int init_module(void)
>> {
>> printk(KERN_INFO "init_module() called\n");
>> ts=kthread_run(thread,NULL,"kthread");
>> return 0;
>> }
>>
>> void cleanup_module(void)
>> {
>> printk(KERN_INFO "cleanup_module() called\n");
>> kthread_stop(ts);
>> }
>> .
>>
>
> In kernel/sched.c
>
> EXPORT_SYMBOL_GPL(sched_setscheduler);
>
> If your driver is not GPL, you can't use it.
>
> Mark

I did it, it worked!!! thank you so much!!!!! :)
-- 
__________________________________________________________________________________

Mónica Puig-Pey González       E-mail: puigpeym@unican.es

Grupo de Computadores y Tiempo Real, Departamento de Electrónica y 
Computadores.
Facultad de Ciencias - Universidad de Cantabria
Av. de los Castros s/n. 39005 - Santander, España
__________________________________________________________________________________
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Changing Kernel thread priorities

[Armin Steinhoff]

Monica Puig-Pey wrote:
> I am writing a driver which has one kernel thread associated with it.
> I want to change the priority of this thread, so that I can specify 
> the order in which it is scheduled following an interrupt.
> I'm using:
>
>  sched_setscheduler(struct task_struct *, int, struct sched_param *);  
> -> sys_sched_setscheduler

http://ftp.au.debian.org/linux-mandocs/2.6.0-test7-full/sys_sched_setscheduler.html

Hope this helps ..

--Armin

>
> but it doesn't work. I tried to change the priority from the 
> init_module, and also from the Kernel Thread, but there is no way.
>
> Kernel version is 2.6.31-11-rt
>
> What do I call to change a kernel thread priority?
>
> Thanks you very much
>
> Mónica
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: I/O operations priority in RTOS

[Nicholas Mc Guire]

On Sat, 04 Jun 2011, Monica Puig-Pey wrote:

> Hello,
> I'm studying how to develop drivers in a real time OS and how do they  
> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
> I would like to know the priority when executing open(), read(), write()  
> and close() operations.
> In my example the thread which is using the driver runs with 10 RTPRIO,  
> but I don't know what happens in kernel context with the priority when  
> running the I/O operations.
> Thank you for your help, I don't know where to learn about this.
>

Priorities are not associated with functions but rather with processes/threads
so the priority with which the functions open/read/write are executed depend
on the process that invokes these functions.

That said there is an indirect impact of the function on priority as soon as
the funciton needs to share any resources that need protection by locking. The
moment that happens the effective execution priority of the function no longer only depends on the task that calls open but may indirectly depedn on a totally
unrelated task that happens to hold a lock protecting some shared resource.

So the consequence for rt-drivers is that they must ensure that they minimize
critical sections, or prevent them all together (i.e. by using lock free 
methods). Notably this puts restrictions on the use of dynamic resources at 
runtime, that is after the driver was initialized - basically you want all 
resources that the rt-driver needs allocated at driver initialization time. 
Also when using bottom half mechanisms you need to take into account the 
priority of the kernel thread that manages the defered work items, so 
rt-drivers may have a different structure than normal drivers.

hofrat

Re: I/O operations priority in RTOS

[Armin Steinhoff]

Nicholas Mc Guire wrote:
> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>
>> Hello,
>> I'm studying how to develop drivers in a real time OS and how do they
>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>> I would like to know the priority when executing open(), read(), write()
>> and close() operations.
>> In my example the thread which is using the driver runs with 10 RTPRIO,
>> but I don't know what happens in kernel context with the priority when
>> running the I/O operations.
>> Thank you for your help, I don't know where to learn about this.
>>
> []
> Also when using bottom half mechanisms you need to take into account the
> priority of the kernel thread that manages the defered work items, so
> rt-drivers may have a different structure than normal drivers.

That's the reason why I prefer UIO based user space drivers !

--Armin

> hofrat
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: I/O operations priority in RTOS

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On 2011-06-05 10:46, Armin Steinhoff wrote:
> Nicholas Mc Guire wrote:
>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>
>>> Hello,
>>> I'm studying how to develop drivers in a real time OS and how do they
>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>> I would like to know the priority when executing open(), read(), write()
>>> and close() operations.
>>> In my example the thread which is using the driver runs with 10 RTPRIO,
>>> but I don't know what happens in kernel context with the priority when
>>> running the I/O operations.
>>> Thank you for your help, I don't know where to learn about this.
>>>
>> []
>> Also when using bottom half mechanisms you need to take into account the
>> priority of the kernel thread that manages the defered work items, so
>> rt-drivers may have a different structure than normal drivers.
> 
> That's the reason why I prefer UIO based user space drivers !

...which are forced to use threaded IRQs over -rt as well.

Taking threaded IRQs out of the picture, bottom-half mechanisms usually
come into play when dispatch workload that cannot be assigned to a
specific user context is significant. But then UIO is the wrong approach
anyway as it doesn't match well the requirements of multi-user device
interfaces.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: I/O operations priority in RTOS

[Armin Steinhoff]

Jan Kiszka wrote:
> On 2011-06-05 10:46, Armin Steinhoff wrote:
>> Nicholas Mc Guire wrote:
>>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>>
>>>> Hello,
>>>> I'm studying how to develop drivers in a real time OS and how do they
>>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>>> I would like to know the priority when executing open(), read(), write()
>>>> and close() operations.
>>>> In my example the thread which is using the driver runs with 10 RTPRIO,
>>>> but I don't know what happens in kernel context with the priority when
>>>> running the I/O operations.
>>>> Thank you for your help, I don't know where to learn about this.
>>>>
>>> []
>>> Also when using bottom half mechanisms you need to take into account the
>>> priority of the kernel thread that manages the defered work items, so
>>> rt-drivers may have a different structure than normal drivers.
>> That's the reason why I prefer UIO based user space drivers !
> ...which are forced to use threaded IRQs over -rt as well.

What's wrong with that approach? You have an ISR in the kernel module 
and an interrupt thread at user space.
Seem OK for me since a long time with QNX :)
> Taking threaded IRQs out of the picture, bottom-half mechanisms usually
> come into play when dispatch workload that cannot be assigned to a
> specific user context is significant. But then UIO is the wrong approach
> anyway as it doesn't match well the requirements of multi-user device
> interfaces.
   Support of multi-user device interfaces at user space is just a 
design issue ... I use this concept since a long time with QNX :)

--Armin



> Jan
>

Re: I/O operations priority in RTOS

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

On 2011-06-06 00:39, Armin Steinhoff wrote:
> Jan Kiszka wrote:
>> On 2011-06-05 10:46, Armin Steinhoff wrote:
>>> Nicholas Mc Guire wrote:
>>>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>>>
>>>>> Hello,
>>>>> I'm studying how to develop drivers in a real time OS and how do they
>>>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>>>> I would like to know the priority when executing open(), read(),
>>>>> write()
>>>>> and close() operations.
>>>>> In my example the thread which is using the driver runs with 10
>>>>> RTPRIO,
>>>>> but I don't know what happens in kernel context with the priority when
>>>>> running the I/O operations.
>>>>> Thank you for your help, I don't know where to learn about this.
>>>>>
>>>> []
>>>> Also when using bottom half mechanisms you need to take into account
>>>> the
>>>> priority of the kernel thread that manages the defered work items, so
>>>> rt-drivers may have a different structure than normal drivers.
>>> That's the reason why I prefer UIO based user space drivers !
>> ...which are forced to use threaded IRQs over -rt as well.
> 
> What's wrong with that approach? You have an ISR in the kernel module
> and an interrupt thread at user space.

Under -rt, you have an ISR kernel thread in addition to whatever threads
you create in user space. I thought your point about UIO was avoiding
the need to worry about priorities, but maybe I misunderstood this.

> Seem OK for me since a long time with QNX :)
>> Taking threaded IRQs out of the picture, bottom-half mechanisms usually
>> come into play when dispatch workload that cannot be assigned to a
>> specific user context is significant. But then UIO is the wrong approach
>> anyway as it doesn't match well the requirements of multi-user device
>> interfaces.
>   Support of multi-user device interfaces at user space is just a design
> issue ... I use this concept since a long time with QNX :)

There is always a tradeoff. IIRC, even QNX is no pure microkernel
anymore when it comes to performance sensitive services that are shared
between many processes. And Linux is no pure monolithic kernel anymore
when it comes to easily implementing user space file systems or
exclusively assigning devices to processes.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: I/O operations priority in RTOS

[Nicholas Mc Guire]

On Sun, 05 Jun 2011, Armin Steinhoff wrote:

> Nicholas Mc Guire wrote:
>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>
>>> Hello,
>>> I'm studying how to develop drivers in a real time OS and how do they
>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>> I would like to know the priority when executing open(), read(), write()
>>> and close() operations.
>>> In my example the thread which is using the driver runs with 10 RTPRIO,
>>> but I don't know what happens in kernel context with the priority when
>>> running the I/O operations.
>>> Thank you for your help, I don't know where to learn about this.
>>>
>> []
>> Also when using bottom half mechanisms you need to take into account the
>> priority of the kernel thread that manages the defered work items, so
>> rt-drivers may have a different structure than normal drivers.
>
> That's the reason why I prefer UIO based user space drivers !
>
...and how to resolve DMA ? if DMA were resolved cleanly I would agree.

hofrat

Re: I/O operations priority in RTOS

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

On 2011-06-05 11:28, Nicholas Mc Guire wrote:
> On Sun, 05 Jun 2011, Armin Steinhoff wrote:
> 
>> Nicholas Mc Guire wrote:
>>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>>
>>>> Hello,
>>>> I'm studying how to develop drivers in a real time OS and how do they
>>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>>> I would like to know the priority when executing open(), read(), write()
>>>> and close() operations.
>>>> In my example the thread which is using the driver runs with 10 RTPRIO,
>>>> but I don't know what happens in kernel context with the priority when
>>>> running the I/O operations.
>>>> Thank you for your help, I don't know where to learn about this.
>>>>
>>> []
>>> Also when using bottom half mechanisms you need to take into account the
>>> priority of the kernel thread that manages the defered work items, so
>>> rt-drivers may have a different structure than normal drivers.
>>
>> That's the reason why I prefer UIO based user space drivers !
>>
> ...and how to resolve DMA ? if DMA were resolved cleanly I would agree.

Regarding that limitation, there is some hope: "next-generation" UIO is
called VFIO. Useful for exclusively assigning virtual PCI functions of
network adapters etc. to user space stacks or hypervisors like QEMU/KVM
(for device pass-through). But it's not mainline yet. And it obviously
requires an IOMMU.

But the key point remains: "exclusively". Anything else cannot be
modeled efficiently via UIO or VFIO.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: I/O operations priority in RTOS

[Nicholas Mc Guire]

On Sun, 05 Jun 2011, Jan Kiszka wrote:

> On 2011-06-05 11:28, Nicholas Mc Guire wrote:
> > On Sun, 05 Jun 2011, Armin Steinhoff wrote:
> > 
> >> Nicholas Mc Guire wrote:
> >>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
> >>>
> >>>> Hello,
> >>>> I'm studying how to develop drivers in a real time OS and how do they
> >>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
> >>>> I would like to know the priority when executing open(), read(), write()
> >>>> and close() operations.
> >>>> In my example the thread which is using the driver runs with 10 RTPRIO,
> >>>> but I don't know what happens in kernel context with the priority when
> >>>> running the I/O operations.
> >>>> Thank you for your help, I don't know where to learn about this.
> >>>>
> >>> []
> >>> Also when using bottom half mechanisms you need to take into account the
> >>> priority of the kernel thread that manages the defered work items, so
> >>> rt-drivers may have a different structure than normal drivers.
> >>
> >> That's the reason why I prefer UIO based user space drivers !
> >>
> > ...and how to resolve DMA ? if DMA were resolved cleanly I would agree.
> 
> Regarding that limitation, there is some hope: "next-generation" UIO is
> called VFIO. Useful for exclusively assigning virtual PCI functions of
> network adapters etc. to user space stacks or hypervisors like QEMU/KVM
> (for device pass-through). But it's not mainline yet. And it obviously
> requires an IOMMU.
> 
> But the key point remains: "exclusively". Anything else cannot be
> modeled efficiently via UIO or VFIO.
> 
for many RT apps that is an acceptable limit - in fact sometimes a requirement - having dynamic access and handling this at runtime is not necessarily an advantage for rt. Giving guarantees on timing for non-exclusive access in the general case would probably need to be based on a priority access model any way (i.e. running non-RT network traffic on a RT-link as "rt-idle" bandwidth usage - but full shared access at runtime would be very hard, if not impossible, to model at the device interface level without breaking RT properties. So I think its legitimate to keep it out of the device all together and let the user apps have a non-rt fight about access...

Any pointers to VFIO ?

hofrat

Re: I/O operations priority in RTOS

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

On 2011-06-06 00:29, Nicholas Mc Guire wrote:
> On Sun, 05 Jun 2011, Jan Kiszka wrote:
> 
>> On 2011-06-05 11:28, Nicholas Mc Guire wrote:
>>> On Sun, 05 Jun 2011, Armin Steinhoff wrote:
>>>
>>>> Nicholas Mc Guire wrote:
>>>>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>>>>
>>>>>> Hello,
>>>>>> I'm studying how to develop drivers in a real time OS and how do they
>>>>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>>>>> I would like to know the priority when executing open(), read(), write()
>>>>>> and close() operations.
>>>>>> In my example the thread which is using the driver runs with 10 RTPRIO,
>>>>>> but I don't know what happens in kernel context with the priority when
>>>>>> running the I/O operations.
>>>>>> Thank you for your help, I don't know where to learn about this.
>>>>>>
>>>>> []
>>>>> Also when using bottom half mechanisms you need to take into account the
>>>>> priority of the kernel thread that manages the defered work items, so
>>>>> rt-drivers may have a different structure than normal drivers.
>>>>
>>>> That's the reason why I prefer UIO based user space drivers !
>>>>
>>> ...and how to resolve DMA ? if DMA were resolved cleanly I would agree.
>>
>> Regarding that limitation, there is some hope: "next-generation" UIO is
>> called VFIO. Useful for exclusively assigning virtual PCI functions of
>> network adapters etc. to user space stacks or hypervisors like QEMU/KVM
>> (for device pass-through). But it's not mainline yet. And it obviously
>> requires an IOMMU.
>>
>> But the key point remains: "exclusively". Anything else cannot be
>> modeled efficiently via UIO or VFIO.
>>
> for many RT apps that is an acceptable limit - in fact sometimes a requirement - having dynamic access and handling this at runtime is not necessarily an advantage for rt. Giving guarantees on timing for non-exclusive access in the general case would probably need to be based on a priority access model any way (i.e. running non-RT network traffic on a RT-link as "rt-idle" bandwidth usage - but full shared access at runtime would be very hard, if not impossible, to model at the device interface level without breaking RT properties. So I think its legitimate to keep it out of the device all together and let the user apps have a non-rt fight about access...

There are good examples - in the RT domain - for both models. Sharing a
device does not necessarily mean making things dynamic or even
unpredictable.

> 
> Any pointers to VFIO ?

E.g. http://thread.gmane.org/gmane.linux.kernel.pci/10088

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: I/O operations priority in RTOS

[Nicholas Mc Guire]

> 
> There are good examples - in the RT domain - for both models. Sharing a
> device does not necessarily mean making things dynamic or even
> unpredictable.
> 

then I maybe dont get the "exclusive" issue you note - if the highest priority task does not have exclusive access - assuming that there is not contention free sharing - how can you give guarantees ? I can imagin sharing if the highest priority has unconstraint access to the reource and any other access is controled by the highest priority task (i.e. queue replication like ARINC 653 queueing ports) but if you have multiple instances of different priority accessing a resource I don't see how this could be done while giving guarantees on timing (assuming that it is not possible to provide all access as physically atomic instructions)

Do you have an example at hand of such a shared I/O device scheme that can guarantee rt timing ?

> > 
> > Any pointers to VFIO ?
> 
> E.g. http://thread.gmane.org/gmane.linux.kernel.pci/10088
>
thanks. 

hofrat

Re: I/O operations priority in RTOS

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

On 2011-06-06 02:21, Nicholas Mc Guire wrote:
>>
>> There are good examples - in the RT domain - for both models. Sharing a
>> device does not necessarily mean making things dynamic or even
>> unpredictable.
>>
> 
> then I maybe dont get the "exclusive" issue you note - if the highest priority task does not have exclusive access - assuming that there is not contention free sharing - how can you give guarantees ? I can imagin sharing if the highest priority has unconstraint access to the reource and any other access is controled by the highest priority task (i.e. queue replication like ARINC 653 queueing ports) but if you have multiple instances of different priority accessing a resource I don't see how this could be done while giving guarantees on timing (assuming that it is not possible to provide all access as physically atomic instructions)

Just the classic way: If there is a critical path while accessing the
device, make it exclusive via locking. If the length of the critical
path is controllable by a low-prio task, you either need to include that
workload in the WCET estimation or you need to apply some limits/quotas
to prevent unbounded path lengths.

> 
> Do you have an example at hand of such a shared I/O device scheme that can guarantee rt timing ?

Let's make it simple: What prevents sharing the process image exposed by
an abstract I/O devices in form of a MMIO region between multiple user
processes? That you may not rely on the hardware to avoid that processes
tap on each other's shoes? But that can be sorted out by privileged
driver that enforces access rules, dispatches variable update events to
listeners or ensures that only consistent modifications are transferred
to the physical process.

Where do we loose RT here?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: I/O operations priority in RTOS

[Armin Steinhoff]

Jan Kiszka wrote:
> On 2011-06-05 11:28, Nicholas Mc Guire wrote:
>> On Sun, 05 Jun 2011, Armin Steinhoff wrote:
>>
>>> Nicholas Mc Guire wrote:
>>>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>>>
>>>>> Hello,
>>>>> I'm studying how to develop drivers in a real time OS and how do they
>>>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>>>> I would like to know the priority when executing open(), read(), write()
>>>>> and close() operations.
>>>>> In my example the thread which is using the driver runs with 10 RTPRIO,
>>>>> but I don't know what happens in kernel context with the priority when
>>>>> running the I/O operations.
>>>>> Thank you for your help, I don't know where to learn about this.
>>>>>
>>>> []
>>>> Also when using bottom half mechanisms you need to take into account the
>>>> priority of the kernel thread that manages the defered work items, so
>>>> rt-drivers may have a different structure than normal drivers.
>>> That's the reason why I prefer UIO based user space drivers !
>>>
>> ...and how to resolve DMA ? if DMA were resolved cleanly I would agree.
> Regarding that limitation, there is some hope: "next-generation" UIO is
> called VFIO.

I found in a posting about VFIO that  " ioctls are used for all the 
basic interactions"  ... that means VFIO works with a lot of context 
switches.
That's not the case with UIO.  So why should VFIO be a mainline approach 
or next generation UIO at all?

--Armin

Re: I/O operations priority in RTOS

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]

On 2011-06-06 09:41, Armin Steinhoff wrote:
> Jan Kiszka wrote:
>> On 2011-06-05 11:28, Nicholas Mc Guire wrote:
>>> On Sun, 05 Jun 2011, Armin Steinhoff wrote:
>>>
>>>> Nicholas Mc Guire wrote:
>>>>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>>>>
>>>>>> Hello,
>>>>>> I'm studying how to develop drivers in a real time OS and how do they
>>>>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>>>>> I would like to know the priority when executing open(), read(),
>>>>>> write()
>>>>>> and close() operations.
>>>>>> In my example the thread which is using the driver runs with 10
>>>>>> RTPRIO,
>>>>>> but I don't know what happens in kernel context with the priority
>>>>>> when
>>>>>> running the I/O operations.
>>>>>> Thank you for your help, I don't know where to learn about this.
>>>>>>
>>>>> []
>>>>> Also when using bottom half mechanisms you need to take into
>>>>> account the
>>>>> priority of the kernel thread that manages the defered work items, so
>>>>> rt-drivers may have a different structure than normal drivers.
>>>> That's the reason why I prefer UIO based user space drivers !
>>>>
>>> ...and how to resolve DMA ? if DMA were resolved cleanly I would agree.
>> Regarding that limitation, there is some hope: "next-generation" UIO is
>> called VFIO.
> 
> I found in a posting about VFIO that  " ioctls are used for all the
> basic interactions"  ... that means VFIO works with a lot of context
> switches.

That mostly refers to configuring VFIO devices (just check the code when
in doubt).

One exception is EIO. VFIO works generically, without any device
specific kernel stubs. So legacy interrupts are first generically
masked, then reported to user space to do the device specific handling,
and then ack'ed by user space via an IOCTL to remove the mask again. But
that only matters for legacy INTx, not for MSI[-X].

> That's not the case with UIO.  So why should VFIO be a mainline approach
> or next generation UIO at all?

Because it is promising to solve the DMA challenge without totally
ignoring security (in contrast to uio-dma). And because it already has
two major use cases (high-speed user space networking and virtualization).

Conceptually, VFIO should be able to cover most of those scenarios that
UIO currently addresses. But UIO is kernel ABI and wouldn't go away even
if VFIO was able to completely replace it.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: I/O operations priority in RTOS

[Armin Steinhoff]

Nicholas Mc Guire wrote:
> On Sun, 05 Jun 2011, Armin Steinhoff wrote:
>
>> Nicholas Mc Guire wrote:
>>> On Sat, 04 Jun 2011, Monica Puig-Pey wrote:
>>>
>>>> Hello,
>>>> I'm studying how to develop drivers in a real time OS and how do they
>>>> work. I'm using  Ubuntu 10.04 with the 2.6.31-11-rt patch installed.
>>>> I would like to know the priority when executing open(), read(), write()
>>>> and close() operations.
>>>> In my example the thread which is using the driver runs with 10 RTPRIO,
>>>> but I don't know what happens in kernel context with the priority when
>>>> running the I/O operations.
>>>> Thank you for your help, I don't know where to learn about this.
>>>>
>>> []
>>> Also when using bottom half mechanisms you need to take into account the
>>> priority of the kernel thread that manages the defered work items, so
>>> rt-drivers may have a different structure than normal drivers.
>> That's the reason why I prefer UIO based user space drivers !
>>
> ...and how to resolve DMA ? if DMA were resolved cleanly I would agree.

https://opensource.qualcomm.com/wiki/UIO-DMA

I haven't tested until now  ... what do you think about it ?

--Armin


> hofrat
>