[rtems commit] sp13: Update configuration to account for messages on fourth message queue
Joel Sherrill
joel.sherrill at oarcorp.com
Wed Apr 15 19:21:52 UTC 2015
Abusing this topic more, this is the complete analysis. I missed the
final loop of create/delete queue. This is the comment in system.h
I have now.
/*
* Created in init.c:
* Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600)
* Q2 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) (160)
* Q3 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600)
*
* Q1 and Q2 deleted in task1.c
*
* Q1 recreated in task1.c
* Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) (2000)
*
* Q1 deleted again in task1.c.
* Q1 repeatedly created and deleted for 2 messages of 1-1030 bytes
* in length
* Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 1030, 2 ) (2000)
*
* Thus the peak message memory needed is technically only:
* Q3 + third instance of Q1 at peak of two 1030 byte messages.
*
*/
#define CONFIGURE_MESSAGE_BUFFER_MEMORY \
CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \
CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 1030, 2 )
On 4/15/2015 1:30 PM, Joel Sherrill wrote:
>
> On 4/15/2015 12:13 PM, Gedare Bloom wrote:
>> On Wed, Apr 15, 2015 at 2:49 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>>> Two message queues get deleted before the forth is created. Why did this
>>> work before and what is the root cause for this failure? We will never know
>>> after this patch.
>>>
>> Yes I don't understand what this is fixing. The test, or the failure?
> Yes. The test under reserves. Here is a more detailed analysis:
>
> For the purposes of this analysis, I am ignoring the overhead per
> allocation.
>
> Before the patch, the configuration was for the initial Q1-Q3 for 3360
> bytes.
>
> MESSAGE_SIZE is a constant in system.h and 16
>
> NEED TOTAL AVAILABLE
> 0 3360
> Q1 - 100 * MESSAGE_SIZE ==> 1600 1600 1760
> Q2 - 10 * MESSAGE_SIZE ==> 160 1760 1600
> Q3 - 100 * MESSAGE_SIZE ==> 1600 3360 0
> delete Q1 1760 1600
> delete Q2 1600 1760
> Q1 - 100 * 20 ==> 2000
>
> Since the second instance of Q1 needs more than the first instance,
> it fails.
>
> Current patch technically over reserves.
>
> Since second instance of Q1 needs more than the first instance,
> we could get by with Q1 second instance, Q2, and Q3 as the
> reservation.
>
> Obviously this would need a comment.
>
> Do you want me to change it that way?
>
>>> On 14/04/15 21:08, Joel Sherril wrote:
>>>> Module: rtems
>>>> Branch: master
>>>> Commit: 351858d75327d5bbda7e720157dced706bbe5688
>>>> Changeset:
>>>> http://git.rtems.org/rtems/commit/?id=351858d75327d5bbda7e720157dced706bbe5688
>>>>
>>>> Author: Joel Sherrill <joel.sherrill at oarcorp.com>
>>>> Date: Tue Apr 14 14:07:35 2015 -0500
>>>>
>>>> sp13: Update configuration to account for messages on fourth message queue
>>>>
>>>> ---
>>>>
>>>> testsuites/sptests/sp13/system.h | 6 +++++-
>>>> testsuites/sptests/sp13/task1.c | 1 +
>>>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/testsuites/sptests/sp13/system.h
>>>> b/testsuites/sptests/sp13/system.h
>>>> index 7bb680c..3b170bf 100644
>>>> --- a/testsuites/sptests/sp13/system.h
>>>> +++ b/testsuites/sptests/sp13/system.h
>>>> @@ -65,10 +65,14 @@ TEST_EXTERN rtems_name Queue_name[ 4 ]; /* array
>>>> of queue names */
>>>> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>>>> +/*
>>>> + * First three created in init.c, last created in task1.c.
>>>> + */
>>>> #define CONFIGURE_MESSAGE_BUFFER_MEMORY \
>>>> CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \
>>>> CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) + \
>>>> - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE )
>>>> + CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \
>>>> + CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 )
>>>> #define CONFIGURE_EXTRA_TASK_STACKS (3 *
>>>> RTEMS_MINIMUM_STACK_SIZE)
>>>> diff --git a/testsuites/sptests/sp13/task1.c
>>>> b/testsuites/sptests/sp13/task1.c
>>>> index e783e37..e104e8d 100644
>>>> --- a/testsuites/sptests/sp13/task1.c
>>>> +++ b/testsuites/sptests/sp13/task1.c
>>>> @@ -267,6 +267,7 @@ rtems_test_pause();
>>>> &Queue_id[ 1 ]
>>>> );
>>>> directive_failed( status, "rtems_message_queue_create of Q1; 20 bytes
>>>> each" );
>>>> +
>>>> status = rtems_message_queue_send( Queue_id[ 1 ], big_send_buffer, 40
>>>> );
>>>> fatal_directive_status(status,
>>>> RTEMS_INVALID_SIZE,
>>>>
>>>> _______________________________________________
>>>> vc mailing list
>>>> vc at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/vc
>>> --
>>> 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.huber at embedded-brains.de
>>> PGP : Public key available on request.
>>>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the devel
mailing list