cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dpekin
Explorer
Explorer
9,262 Views
Registered: ‎07-09-2012

Zynq Linux pthread scheduling

Jump to solution

Hi there,

 

We're using pthreads to start various threads.  Most threads are not high priority so we leave the scheduling mode as SCHED_OTHER.  A few threads are more time critical so we're upping their policy to SCHED_RR and upping their priority.  

 

The problem is that I'm not seeing any difference in performance when I do this.  To test this I created 2 CPU intensive threads doing exactly the same thing, a bunch of calc, short sleep, loop.  After N cycles of the loop I report the elapsed time it took to do the N loops.  The time for N loops is approximately 4 seconds and "top" reports CPU usage for the executable that spawned the threads at about 70%.   

 

Then to force more loading on the zynq I performed a large file copy to flash memory.  As expected, the file copy took a significant amount of CPU/kernel time and the reported CPU usage for my test executable dropped from ~70% to ~50%.

 

I would have expected the SCHED_RR thread to be allocated more CPU cycles than the SCHED_OTHER task now that the system was CPU burdened.  It turns out that both threads were still allocated equal, albiet reduced,  CPU resources....  The time for N loops on each thread increased from ~4 seconds to ~6.5 seconds.

 

I setup the thread priorities and start the threads by calling: 

...

ret  = pthread_attr_setschedpolicy(&list->attr, policy);

...

ret = pthread_attr_setschedparam(&list->attr, &pri);

...

ret = pthread_create(&list->tid,
&list->attr,
(void *)sysi_startThread,
list);

...

 

There are no error codes on the calls.  

 

Does anyone have any thoughts on this?  

 

Thanks,

 

- Dave

0 Kudos
1 Solution

Accepted Solutions
dpekin
Explorer
Explorer
16,327 Views
Registered: ‎07-09-2012

Hello All,

 

I discovered the problem!

 

One must make the pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED)  call prior to making the pthread_create(...) call.

 

Without this call, the new thread will inherit the attributes of the caller.  This functionality is apparently different between Linux distributions as this same code (without the new call) worked on Linux 3.6 on a different ARM target.  We're using 3.10 now.

 

Thanks,

 

- Dave

View solution in original post

0 Kudos
4 Replies
guillaumebres
Scholar
Scholar
9,255 Views
Registered: ‎03-27-2014

We're using pthreads to start various threads.  Most threads are not high priority so we leave the scheduling mode as SCHED_OTHER.  A few threads are more time critical so we're upping their policy to SCHED_RR and upping their priority.  

my understanding is that threading reduces the speed of an application since it requires pretty advanced stuff (creating/killing tasks), though I am not sure if that's true if one is able to assign one task to a particular CPU.

 

what if you had the highest priority operations in a normal while(1) loop, and try to perform lower priority tasks by checking a mutex like

while(1){
    [high priority...]

    status = pthread_mutex_trylock(&lp_task_mutex);
    if(status == 0)
    {
        --you got the lock
        pthread_mutex_unlock(&lp_task_mutex);
        --create tasklet
        status = pthread_create(&task, NULL, pthread_lp_task, (void*)tmp);
    }
}

this way you only 'thread' the low priority operations,

if you can't , you still perform higher priority actions.

 

 

You may increase the processing time by assigning your low prority threads on the second CPU and do the most important things on the first one, but I don't know if that's doable and would give significant improvements: I need to try it.

gw.
Embedded Systems, DSP, cyber
0 Kudos
dpekin
Explorer
Explorer
9,249 Views
Registered: ‎07-09-2012
Thanks for the thought. The threading architecture is already established and working on other Linux platforms so changing the approach isn't viable. My problem is that I'm not getting the expected scheduling/priority performance on the ZYNQ that I saw on other ARM platforms.
0 Kudos
dpekin
Explorer
Explorer
16,328 Views
Registered: ‎07-09-2012

Hello All,

 

I discovered the problem!

 

One must make the pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED)  call prior to making the pthread_create(...) call.

 

Without this call, the new thread will inherit the attributes of the caller.  This functionality is apparently different between Linux distributions as this same code (without the new call) worked on Linux 3.6 on a different ARM target.  We're using 3.10 now.

 

Thanks,

 

- Dave

View solution in original post

0 Kudos
milosoftware
Scholar
Scholar
9,177 Views
Registered: ‎10-26-2012

What I've been using in the past is just calling methods to set priority (in particular, IO priority) from within the thread itself. Though the man pages are a bit fuzzy about process and thread boundaries, most of these functions only operate on the current thread and not on the process as a whole.

0 Kudos