[PATCH] sp13: Document message buffer usage and adjust configuration

[Joel Sherrill]

On 4/16/2015 11:14 AM, Gedare Bloom wrote:
> Do you have any intuition to answer Sebastian's concern about why this
> test suddenly exposed a problem? (git-bisect?)
No. There have been so many changes lately that I assume something got
tighter
in confdefs.h. That's usually what it is.

In general, any test with message queues was exceedingly sloppy before we
have confdefs parameters for message buffers. This one just got tuned too
low and as we tightened confdefs.h, it broke.
> On Thu, Apr 16, 2015 at 11:55 AM, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
>> ---
>>  testsuites/sptests/sp13/system.h | 31 ++++++++++++++++++++++++++-----
>>  1 file changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/testsuites/sptests/sp13/system.h b/testsuites/sptests/sp13/system.h
>> index 3b170bf..f879096 100644
>> --- a/testsuites/sptests/sp13/system.h
>> +++ b/testsuites/sptests/sp13/system.h
>> @@ -66,13 +66,34 @@ 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.
>> + *  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. Account for peak usage:
>> + *    Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 2, 1030 )           (2060)
>> + *
>> + *  Because each message requires memory for the message plus two
>> + *  pointers to place the buffer on lists, it is easier to just
>> + *  allocate memory for all the message queues. But we can safely
>> + *  ignore Q2 and the last instance of Q1 since enough memory is
>> + *  free when the third instance of Q1 is created.
>>   */
>>  #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, 20 )
>> +   /* Q1 */ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \
>> +   /* Q2 */ /* CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) + */ \
>> +   /* Q3 */ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \
>> +   /* Q1 */ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) + \
>> +   /* Q1 */ /* CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 2,  1030 ) */
>>
>>  #define CONFIGURE_EXTRA_TASK_STACKS         (3 * RTEMS_MINIMUM_STACK_SIZE)
>>
>> --
>> 1.9.3
>>
>> _______________________________________________
>> 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