Re: MrsP Testbed
On 10/09/2019 15:56, Ricardo Gomes (1161078) wrote: In this email I sending one test for you to review it and see if it is structured according to RTEMS coding conventions, that I tried to fulfill. This test case is very simple, testing only if it is possible to set one priority per scheduling instance and also verifying if, when a task attempt to obtain a MrsP semaphore, its priority is immediately raised to the ceiling priority defined on its scheduler. I am currently quite busy. Please remind me in one week. Could you please change the licence to: https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause Please send a complete patch so that I can build your test case and run it. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
MrsP Testbed
Hello Sebastian,
>> Greetings,
>>
>> During the last six months, I have been studying RTEMS as part of my final
>> project to complete my degree, more specifically analysing the MrsP
>> protocol in
>> order to perform an evaluation of its implementation on RTEMS.
> I would be great if you can publish the evaluation once it is finished.
> Please let me know if you need a > reviewer.
>> In order to accomplish this analysis, I developed a set of samples that
>> allows
>> one to test several properties of MrsP, based its own rules, as described in
>> [1], including the use of nested resources, presented in [2]. Beyond that,
>> I
>> have also adapted those test cases, using OMIP instead of MrsP, in order to
>> establish comparisons between both protocols.
>>
>> So far the set of develop test cases were executed using QEMU, as up to now
>> I’m
>> not able to execute SMP code in a Raspberry PI 2 (I will address this topic
>> with more detail later on another thread).
>>
>> I wanted to know if:
>>
>> 1- there is any interest from the community for me to submit these tests to
>> the
>> RTEMS repository, or at least the ones considered relevant
>>
>> 2- In case the answer to 1 is affirmative, If I should create a new ticket
>> and
>> submit the test cases as individual patches.
> an independent set of test cases would be good. Currently, the tests and the
> implementation are from > the same person. SMP test code in the test suite
> must compile and link on all SMP targets. If you plan > to submit the code,
> please plan with enough time for some review/change iterations.
In first place, yes I want to submit my tests, although how may I assert if my
tests compile and link on every SMP targets?
>>
>> Thank you for your attention.
>>
>> Best Regards,
>
>> Ricardo Gomes
>>
>>
>> P.S. After I complete my final report I can make it available if someone is
>> interested.
> Yes, I am definitely interested.
In this email I sending one test for you to review it and see if it is
structured according to RTEMS coding conventions, that I tried to fulfill.
This test case is very simple, testing only if it is possible to set one
priority per scheduling instance and also verifying if, when a task attempt to
obtain a MrsP semaphore, its priority is immediately raised to the ceiling
priority defined on its scheduler.
Best regards,
Ricardo Gomes
<>
/*
* Copyright (c) 2019 Ricardo Gomes - CISTER
*
* The license and distribution terms for this file may be
* found in the file LICENSE in this distribution or at
* https://www.rtems.org/license/LICENSE.
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include
#include
#include
#include
#include
#include "tmacros.h"
const char rtems_test_name[] = "SMPMRSP 2";
#define CPU_COUNT 2
typedef struct
{
rtems_id init_id;
rtems_id scheduler_ids[CPU_COUNT];
rtems_id mrsp_id;
rtems_id task_id;
} test_context;
static test_context test_instance;
static void assert_priority(rtems_id task_id, rtems_task_priority priority)
{
rtems_status_code sc;
rtems_task_priority prio;
sc = rtems_task_set_priority(task_id, RTEMS_CURRENT_PRIORITY, );
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
rtems_test_assert(priority == prio);
}
static void create_mrsp_semaphore(test_context *ctx, rtems_id *id,
rtems_task_priority prio)
{
uint32_t cpu_count = rtems_get_processor_count();
uint32_t index;
rtems_status_code sc;
sc = rtems_semaphore_create(
rtems_build_name('M', 'R', 'S', 'P'),
1,
RTEMS_MULTIPROCESSOR_RESOURCE_SHARING | RTEMS_BINARY_SEMAPHORE,
prio,
id);
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
rtems_task_priority old_prio;
old_prio = 1;
sc = rtems_semaphore_set_priority(
*id,
ctx->scheduler_ids[1],
prio + 1,
_prio);
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
prio = 2;
for (index = 0; index < cpu_count; index++)
{
rtems_task_priority pr = RTEMS_CURRENT_PRIORITY;
sc = rtems_semaphore_set_priority(*id, ctx->scheduler_ids[index], pr, );
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
rtems_test_assert(prio == pr);
printf("CPU %d ceiling priority = %" PRIu32 "\n", index, pr);
prio++;
}
}
static void test_prio_per_proc(test_context *ctx)
{
printf("\n\n--TESTING IF THERE IS ONE CEILING PER PROCESSOR--\n\n");
rtems_task_priority prio = 2;
create_mrsp_semaphore(ctx, >mrsp_id, prio);
printf("\n-\n");
}
static void high_task_prio_obtain(rtems_task_argument arg)
{
test_context *ctx = _instance;
printf("TASK - before obtain should the prio should be 6\n");
assert_priority(RTEMS_SELF, 6);
rtems_status_code sc = rtems_semaphore_obtain(ctx->mrsp_id, RTEMS_WAIT,
RTEMS_NO_TIMEOUT);
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
printf("TASK - after obtain should the prio should be 3\n");
assert_priority(RTEMS_SELF, 3);
sc = rtems_semaphore_release(ctx->mrsp_id);
Re: MrsP Testbed
Hello Ricardo, - Am 4. Sep 2019 um 15:52 schrieb Ricardo Gomes (1161078) 1161...@isep.ipp.pt: > Greetings, > > During the last six months, I have been studying RTEMS as part of my final > project to complete my degree, more specifically analysing the MrsP protocol > in > order to perform an evaluation of its implementation on RTEMS. I would be great if you can publish the evaluation once it is finished. Please let me know if you need a reviewer. > In order to accomplish this analysis, I developed a set of samples that allows > one to test several properties of MrsP, based its own rules, as described in > [1], including the use of nested resources, presented in [2]. Beyond that, I > have also adapted those test cases, using OMIP instead of MrsP, in order to > establish comparisons between both protocols. > > So far the set of develop test cases were executed using QEMU, as up to now > I’m > not able to execute SMP code in a Raspberry PI 2 (I will address this topic > with more detail later on another thread). > > I wanted to know if: > > 1- there is any interest from the community for me to submit these tests to > the > RTEMS repository, or at least the ones considered relevant > > 2- In case the answer to 1 is affirmative, If I should create a new ticket and > submit the test cases as individual patches. an independent set of test cases would be good. Currently, the tests and the implementation are from the same person. SMP test code in the test suite must compile and link on all SMP targets. If you plan to submit the code, please plan with enough time for some review/change iterations. > > Thank you for your attention. > > Best Regards, > > Ricardo Gomes > > > P.S. After I complete my final report I can make it available if someone is > interested. Yes, I am definitely interested. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
MrsP Testbed
Greetings, During the last six months, I have been studying RTEMS as part of my final project to complete my degree, more specifically analysing the MrsP protocol in order to perform an evaluation of its implementation on RTEMS. In order to accomplish this analysis, I developed a set of samples that allows one to test several properties of MrsP, based its own rules, as described in [1], including the use of nested resources, presented in [2]. Beyond that, I have also adapted those test cases, using OMIP instead of MrsP, in order to establish comparisons between both protocols. So far the set of develop test cases were executed using QEMU, as up to now I’m not able to execute SMP code in a Raspberry PI 2 (I will address this topic with more detail later on another thread). I wanted to know if: 1- there is any interest from the community for me to submit these tests to the RTEMS repository, or at least the ones considered relevant 2- In case the answer to 1 is affirmative, If I should create a new ticket and submit the test cases as individual patches. Thank you for your attention. Best Regards, Ricardo Gomes P.S. After I complete my final report I can make it available if someone is interested. References: [1] Alan Burns, Andy Wellings, “A schedulability Compatible Multiprocessos Resource Sharing Protocol - MrsP,” . In: 25th Euromicro Conference on Real-Time Systems (ECRTS) (2013) [2] B. Brandenburg, “A Fully Preemptive Multiprocessor Semaphore Protocol for Latency-Sensitive Real-Time Applications,” in Proceedings of the 25th Euromicro Conference on Real-Time Systems (ECRTS), Paris, 2013. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
