Re: [Xenomai] Round robin scheduling seem not working in a specific case...

[Christophe Carton <christophe.carton@ixblue.com>]

Le 04/11/2014 15:09, Christophe Carton a écrit :
>
> Le 04/11/2014 15:05, Philippe Gerum a écrit :
>> On 11/04/2014 02:49 PM, Christophe Carton wrote:
>>> Le 04/11/2014 14:22, Philippe Gerum a écrit :
>>>> On 11/04/2014 12:46 PM, Gilles Chanteperdrix wrote:
>>>>> On Tue, Nov 04, 2014 at 12:43:00PM +0100, Philippe Gerum wrote:
>>>>>> On 11/04/2014 11:34 AM, Christophe Carton wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am currently working with Xenomai 2.6.4 with native skin and 
>>>>>>> with a
>>>>>>> Linux kernel 3.14.17.
>>>>>>> The linux and the xenomai have been taken from the following Git
>>>>>>> repositories :
>>>>>>> * http://git.xenomai.org/xenomai-2.6.git - tag v2.6.4
>>>>>>> * http://git.xenomai.org/ipipe.git - tag ipipe-core-3.14.17-x86-4
>>>>>>>
>>>>>>> I am encountering a problem to enable the Round Robin scheduler 
>>>>>>> in a
>>>>>>> specific case :
>>>>>>> * Two tasks ("rr task 1" and "rr task 2") of priority 10 are
>>>>>>> launched by
>>>>>>> a task ("init task") of priority 90.
>>>>>>> * All 3 of them are configured with a RR scheduler via 
>>>>>>> "rt_task_slice"
>>>>>>> API before they are started.
>>>>>>> In this case the FIFO scheduling seems to be applied (could be seen
>>>>>>> via
>>>>>>> rt_printf logs).
>>>>>>>
>>>>>>> I have found a thread on the mailing list that gives an example
>>>>>>> demonstrating the good behavior of the RR scheduler.
>>>>>>> http://www.xenomai.org/pipermail/xenomai/2011-November/024897.html
>>>>>>> http://www.xenomai.org/pipermail/xenomai/2011-November/024899.html
>>>>>>> This example implies that the tasks are locked via a semaphore at
>>>>>>> startup and that this semaphore is unlocked by the main when all
>>>>>>> threads
>>>>>>> have been started.
>>>>>>> This is necessary in this case due to the fact that the main
>>>>>>> function is
>>>>>>> no an RT task.
>>>>>>>
>>>>>>> This implementation (with the semaphore) applied to my test 
>>>>>>> works. Why
>>>>>>> is the semaphore needed in my case?
>>>>>> init_task() is switched to non-rt mode by rt_task_create(), so 
>>>>>> that a
>>>>>> regular pthread is first created by the glibc, prior to extending it
>>>>>> with Xenomai capabilities. In 2.6.x, this operation leaves the 
>>>>>> caller
>>>>>> (i.e. init_task() in your case) in relaxed/secondary mode, which 
>>>>>> means
>>>>>> that it is assigned the lowest priority level in the Xenomai 
>>>>>> scheduler,
>>>>>> below the RR class.
>>>>>>
>>>>>> Given that, in your code, no Xenomai syscall following the first
>>>>>> rt_task_create() have the requirement to switch the caller back to
>>>>>> primary/rt mode, including rt_task_start() which is issued for 
>>>>>> task_1.
>>>>>> Hence init_task() won't compete with task() which is assigned the
>>>>>> real-time RR priority you asked for on entry.
>>>>>>
>>>>>> IOW, if you don't make the children wait on a barrier until the 
>>>>>> parent
>>>>>> has set the whole thing up, the first call to rt_task_start() will
>>>>>> unleash task_1, which will in turn start spinning immediately in its
>>>>>> work loop as init_task() is on a lower priority level, locking up
>>>>>> CPU#1.
>>>>>>
>>>>> Right. You can probably avoid that by enabling the deprecated option
>>>>> CONFIG_XENO_OPT_PRIOCPL in the kernel configuration.
>>>>>
>>>> I would not recommend to rely on this option, as you know we killed it
>>>> in 3.x because we could never have it working 100% reliably. The only
>>>> sane way otherwise is to synchronize the parent and the child thread
>>>> internally at thread creation to preserve the priority order, without
>>>> requiring the start call to switch to secondary mode, but only 3.x
>>>> implements this.
>>>>
>>> Thanks for your replies.
>>> I do now understand why my code example is not working like I supposed
>>> it should have.
>>>
>>> It looks like rt_task_create() and rt_task_start() switches the caller
>>> in relaxed/secondary mode. This explains the behavior that I have 
>>> noticed.
>>> I have read the doxygen documentation about those two API and I did not
>>> find this behavior explained.
>>> How could we know which API switches the caller's mode to primary/rt or
>>> to relaxed/secondary or maybe does not affect the mode?
>>>
>> This behavior was not documented in the 2.6.x series, which is clearly
>> unfortunate. As a suggestion, here is fallback option :
>>
>> - first refer to the 3.x documentation for the same call, looking for
>> the service "Tags" section, e.g. for rt_task_create() that would be:
>> http://www.xenomai.org/documentation/xenomai-3/html/xeno3prm/group__alchemy__task.html#ga03387550693c21d0223f739570ccd992 
>>
>> with tags mentioning "thread-unrestricted, switch-secondary".
>> Clicking on the tags will get you the explanation:
>> http://www.xenomai.org/documentation/xenomai-3/html/xeno3prm/api-tags.html 
>>
>>
>> - then cross-check with the 2.x -> 3.x migration info that the
>> documented behavior did not change, or in which way it did change. For
>> the task-related stuff from the API you are using, the info would be 
>> there:
>> http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Task_management
>>
>> Well, ok. I agree in advance that it's not that handy.
>>
>
> OK.
> I will do with this fallback option for the moment until I migrate to 
> Xenomai 3.x.
> Thanks to the team for the quick replies.
>
> Best regards,
>

Hi,

I have taken into account your previous replies and added after 
rt_task_create(), rt_task_set_mode(0, T_CONFORMING, nullptr) to set 
init_task()'s mode from relaxed/secondary mode to primary/rt mode.
task_1 and task_2 are launched when init_task() calls the rt_task_join() 
which is the waited behavior.
Nevertheless, they are are still not scheduled in RR...
As init_task() is in primary/rt mode and of higher priority than task_1 
and task_2, shouldn't we have task_1 and task_2 launched "at the same 
time" and scheduled in RR?
It looks like rt_task_start() does not immediately declare task_1() and 
task_2() to the scheduler (and so, the scheduler does not set them in 
suspended state until init_task() is suspended). In other words, 
task_1() and task2() seems to be declared to the scheduler only when 
init_task() is suspended (and so launched one after the other - this 
could explain the observed behavior).
Is this correct? Does this means that the children must always wait on a 
barrier until the parents has finish it setup?

You could find attached the updated source code.

Best regards,

-- 

*Christophe Carton *

-------------- next part --------------
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <math.h>
#include <assert.h>

#include <xenomai/native/timer.h>
#include <xenomai/native/task.h>
#include <xenomai/native/sem.h>

#include <rtdk.h>

#define NB_TASKS (2UL)

#define EXECTIME_NS (100e6) // 100 ms
#define WORKTIME_NS (500e3) // 500 µs
#define CPU_ID (1)
RT_SEM synchro_sem;

RTIME slice = 2; //rt_timer_ns2ticks(20000);

#define ERROR_MGR(fct) \
do { \
	int err = fct; \
	if ( err != 0 ) \
	{ \
		rt_fprintf(stderr, "%s-%s error %d\n", __FUNCTION__, #fct, err); \
		abort(); \
	} \
}while(0)

#define TASK_INQUIRE(str) \
do \
{ \
	RT_TASK_INFO info; \
	ERROR_MGR( rt_task_inquire(nullptr, &info) ); \
	rt_printf( \
		"[%s]\n" \
		"\t- Mode switches = %d\n" \
		"\t- Base Prio     = %d\n" \
		"\t- Current Prio  = %d\n", \
		str, \
		info.modeswitches, \
		info.bprio, info.cprio); \
} while(0)

#define TASK2PRIMARY() \
do { \
	ERROR_MGR( rt_task_set_mode(0, T_CONFORMING, nullptr) ); \
}while(0)

static void task(void *)
{
	TASK_INQUIRE(__FUNCTION__);

//	ERROR_MGR( rt_task_sleep(rt_timer_ns2ticks(500000000)) );
//	ERROR_MGR( rt_sem_p(&synchro_sem, TM_INFINITE) );

	RT_TASK_INFO curtaskinfo;
	RT_TASK *curtask = nullptr;
	ERROR_MGR( rt_task_inquire(curtask, &curtaskinfo) );
	for(  ; curtaskinfo.exectime < EXECTIME_NS ;  )
	{
		rt_timer_spin(WORKTIME_NS);
		// dummy average processing
		ERROR_MGR( rt_task_inquire(curtask, &curtaskinfo) );
		RTIME timepoint = rt_timer_read();
		rt_printf(
				"%lu Running [%s] priority [%d] at : [%lu ns]\n",
				timepoint,
				curtaskinfo.name,
				curtaskinfo.cprio,
				curtaskinfo.exectime);
	}
}

static void init_task(void *)
{
	RT_TASK task_desc_1, task_desc_2;

	TASK_INQUIRE(__FUNCTION__);

	ERROR_MGR( rt_task_create ( &task_desc_1, "rr task 1", 0, 10, T_JOINABLE | T_CPU(CPU_ID) ) );

	ERROR_MGR( rt_task_create ( &task_desc_2, "rr task 2", 0, 10, T_JOINABLE | T_CPU(CPU_ID) ) );
	TASK_INQUIRE("rt_task_create 2");
	TASK2PRIMARY();

//	rt_printf("slice ticks = %lu\n", slice);
	ERROR_MGR( rt_task_slice( &task_desc_1, slice ) );

	ERROR_MGR( rt_task_slice( &task_desc_2, slice ) );

	ERROR_MGR( rt_task_start( &task_desc_1, &task, nullptr ) );

	ERROR_MGR( rt_task_start( &task_desc_2, &task, nullptr ) );
	TASK_INQUIRE("rt_task_start 2");

//	rt_printf("Launch!!!\n");
//	rt_task_sleep(rt_timer_ns2ticks(500000000UL));
//	ERROR_MGR( rt_sem_broadcast(&synchro_sem) );

	ERROR_MGR( rt_task_join( &task_desc_1 ) );
	ERROR_MGR( rt_task_join( &task_desc_2 ) );
}

int main (int argc, char* argv[])
{
	(void)argc;
	(void)argv;
	RT_TASK init_task_desc;
	
	ERROR_MGR( mlockall( MCL_CURRENT | MCL_FUTURE ) );

	rt_print_auto_init(1);

	// semaphore to sync task startup on
	ERROR_MGR( rt_sem_create(&synchro_sem, "Synchro sem", 0, S_FIFO) );

	ERROR_MGR( rt_task_create( &init_task_desc, "init task", 0, 90, T_JOINABLE | T_CPU(CPU_ID) ) );

	ERROR_MGR( rt_task_slice( &init_task_desc, slice ) );

	ERROR_MGR( rt_task_start( &init_task_desc, &init_task, nullptr ) );

	ERROR_MGR( rt_task_join( &init_task_desc ) );

	ERROR_MGR( rt_sem_delete(&synchro_sem) );

	return EXIT_SUCCESS;
}