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.hu...@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.sherr...@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 >>>> v...@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.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 >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
