[ECOS] Stack usage measurement

[ECOS] Stack usage measurement

[Szentirmai Gergely]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

Hello

I had a bad feeling about stack usage (perhaps measurement), and I have 
written a small testcode, to see what's really happening. It came with 
an interesting result. It seems to me, that 
cyg_thread_info.stack_used gives the max used stack size, not the 
actual. Is that right? According to the docs, it should give the current 
usage.

The test code is attached, I use arm-elf-gcc, ecos with default packages.

The result is also attached. I think that even the last stack usage 
should be equal with 144 Bytes.

Maybe I am wrong... maybe not.

Thank you!
Gergely Szentirmai

[-- Attachment #2: stacktest.c --]
[-- Type: text/plain, Size: 2749 bytes --]

#include <stdio.h>
#include <cyg/infra/diag.h>
#include <cyg/hal/hal_arch.h>
#include <cyg/kernel/kapi.h>
#include <stdlib.h>

/*******************/
/***   Threads   ***/
/*******************/

#define MAIN_THREAD_STACK_SIZE CYGNUM_HAL_STACK_SIZE_MINIMUM*3
cyg_uint8 main_thread_stack[MAIN_THREAD_STACK_SIZE];
cyg_handle_t main_thread_handle;
cyg_thread main_thread_obj;

void show_thread(cyg_handle_t thread)
{
	cyg_uint16 id=cyg_thread_get_id(thread);
    cyg_thread_info info;

    if( !cyg_thread_get_info( thread, id, &info ) )
    {
    	diag_printf("Unable to get thread info\n");
        return;
    }
    diag_write_dec(info.stack_used);
    diag_printf(" Bytes used\n");
}


void stacktest3(void)
{
	char test2[1512]="In this test we allocate (1512 Bytes), and we print out the stack usage\n\0";
	diag_printf(test2);
	show_thread(main_thread_handle);	
}


void stacktest2(void)
{
	char test2[512]="Test data2 allocated (512 Bytes) in the called function, on the stack\n\0";
	diag_printf(test2);
}


void stacktest(void)
{
	char test[1024]="Test data allocated (1024 Bytes) in the called function, on the stack\n\0";
	diag_printf(test);

}
static void main_thread(cyg_addrword_t index)
{
	show_thread(main_thread_handle);
	show_thread(main_thread_handle);
	diag_printf("Stack usage should be the same, but it is not.\n");
	show_thread(main_thread_handle);
	diag_printf("Calling the test function\n");
	stacktest();
	diag_printf("function returned, let's see the stack size, it should be the same as before\n");
	show_thread(main_thread_handle);
	diag_printf("now we call it again\n");
	stacktest();
	diag_printf("function returned, let's see the stack size, it should be the same as before\n");
	show_thread(main_thread_handle);
	diag_printf("now we the second test function\n");
	stacktest2();
	diag_printf("function returned, let's see the stack size, it should be the same as before\n");
	show_thread(main_thread_handle);
	diag_printf("now we the third test function\n");
	stacktest3();
	diag_printf("function returned, let's see the stack size, it should be the same as before call\n");
	show_thread(main_thread_handle);
	
	while(1)
	{
		diag_printf("main loop\n");	 		
		cyg_thread_delay(1000);
		show_thread(main_thread_handle);
	}
}

/****************/
/***   Init   ***/
/****************/

void cyg_user_start(void)
{
	diag_init();
	diag_printf("\n");
	diag_printf("---- User-start ---\n");

	cyg_thread_create(
		10,						// priority
		main_thread,			// thread function
		0,						// thread parameter
		NULL,					// thread name
		&main_thread_stack,		// stack base addr
		MAIN_THREAD_STACK_SIZE,	// stack size
		&main_thread_handle,	// thread handle
		&main_thread_obj);		// thread object
	cyg_thread_resume(main_thread_handle);
}

[-- Attachment #3: result.txt --]
[-- Type: text/plain, Size: 908 bytes --]

---- User-start ---
144 Bytes used
332 Bytes used
Stack usage should be the same, but it is not.
440 Bytes used
Calling the test function
Test data allocated (1024 Bytes) in the called function, on the stack
function returned, let's see the stack size, it should be the same as before
1484 Bytes used
now we call it again
Test data allocated (1024 Bytes) in the called function, on the stack
function returned, let's see the stack size, it should be the same as before
1484 Bytes used
now we the second test function
Test data2 allocated (512 Bytes) in the called function, on the stack
function returned, let's see the stack size, it should be the same as before
1484 Bytes used
now we the third test function
In this test we allocate (1512 Bytes), and we print out the stack usage
1972 Bytes used
function returned, let's see the stack size, it should be the same as before call
1972 Bytes used
main loop


[-- Attachment #4: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Stack usage measurement

[Gary Thomas]

Szentirmai Gergely wrote:
> Hello
> 
> I had a bad feeling about stack usage (perhaps measurement), and I have
> written a small testcode, to see what's really happening. It came with
> an interesting result. It seems to me, that cyg_thread_info.stack_used
> gives the max used stack size, not the actual. Is that right? According
> to the docs, it should give the current usage.
> 
> The test code is attached, I use arm-elf-gcc, ecos with default packages.
> 
> The result is also attached. I think that even the last stack usage
> should be equal with 144 Bytes.
> 
> Maybe I am wrong... maybe not.

No, you are correct, the value is the maximum used.  Why is this
less useful than the 'current' used?  Stacks aren't reused or
dynamic (they don't grow or shrink), so [IMO] the most useful
measurement is the max size you'll ever need, which is the
measured value [at the time of the measurement, of course]

In addition, every call your code makes to 'diag_printf()'
perturbs the measurement, as it can use a lot of stack itself!
If you want to be very pure about the measurements, save the
stack information in some variables and only print the results
when done, that way 'diag_printf()'s use won't get in the way.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Stack usage measurement

[Szentirmai Gergely]

Gary Thomas írta:
> Szentirmai Gergely wrote:
>> Hello
>>
>> I had a bad feeling about stack usage (perhaps measurement), and I have
>> written a small testcode, to see what's really happening. It came with
>> an interesting result. It seems to me, that cyg_thread_info.stack_used
>> gives the max used stack size, not the actual. Is that right? According
>> to the docs, it should give the current usage.
>>
>> The test code is attached, I use arm-elf-gcc, ecos with default packages.
>>
>> The result is also attached. I think that even the last stack usage
>> should be equal with 144 Bytes.
>>
>> Maybe I am wrong... maybe not.
> 
> No, you are correct, the value is the maximum used.  Why is this
> less useful than the 'current' used?  Stacks aren't reused or
> dynamic (they don't grow or shrink), so [IMO] the most useful
> measurement is the max size you'll ever need, which is the
> measured value [at the time of the measurement, of course]

I agree with you, but I was interrested about the current usage in this 
case. I thought that the difference between cyg_thread_info.stack_used 
and cyg_thread_measure_stack_usage 
(CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT enabled) is exactly this 
(current vs max usage). If both measure the max usage, than what is the 
difference? cyg_thread_measure_stack_usage is just a shortcut to the same?

> 
> In addition, every call your code makes to 'diag_printf()'
> perturbs the measurement, as it can use a lot of stack itself!
> If you want to be very pure about the measurements, save the
> stack information in some variables and only print the results
> when done, that way 'diag_printf()'s use won't get in the way.
> 

This is one of the things why I would like to measure the current usage.
I have tried to minimize this effect by avoid any %d and use 
diag_write_dec(info.stack_used); So diag_printf only have to push the 
string out.

  My initialization thread now use 3k+ stack, which is way to much (I 
have 32k of SRAM) from a simple initialization thread. I think 
"printf-s" has a big part in it (trace, log etc.).
Does anybody has a estimation about the stack usage of pintf stuff? I 
think it should use about the length of the printed text, and some more 
because of the calling parameters. I know that it is depending on the 
implementation.

As a summary, I would have to avoid the usage of any printf if I'm short 
of memory?

In this case I would implement a stack usage optimalized printf 
(statically allocated (or malloc) working buffer) for debugging purpose.

Thank you!
Gergely Szentirmai

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Stack usage measurement

[Ross Younger]

Szentirmai Gergely wrote:
> Does anybody has a estimation about the stack usage of pintf stuff? [...]
> As a summary, I would have to avoid the usage of any printf if I'm short
> of memory?

printf (or, more precisely, the actual format conversion in vfnprintf) is
really quite a complicated function. This regularly bites people on limited
targets; sometimes simply using printf is enough to cause your application
to fail to link because it won't fit into RAM.

If you don't need to print out floating point numbers, you might save a
little code size by disabling that support in your eCos config. Otherwise,
puts and putc are pretty lean and mean - you could save a lot of code and
stack if you can avoid printf in your application.


Ross

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  www.ecoscentric.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Stack usage measurement

[Gary Thomas]

Ross Younger wrote:
> Szentirmai Gergely wrote:
>> Does anybody has a estimation about the stack usage of pintf stuff? [...]
>> As a summary, I would have to avoid the usage of any printf if I'm short
>> of memory?
> 
> printf (or, more precisely, the actual format conversion in vfnprintf) is
> really quite a complicated function. This regularly bites people on limited
> targets; sometimes simply using printf is enough to cause your application
> to fail to link because it won't fit into RAM.
> 
> If you don't need to print out floating point numbers, you might save a
> little code size by disabling that support in your eCos config. Otherwise,
> puts and putc are pretty lean and mean - you could save a lot of code and
> stack if you can avoid printf in your application.

Good points, but 'diag_printf()' is already quite stripped; no floating point.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Stack usage measurement

[Szentirmai Gergely]

Gary Thomas írta:
> Ross Younger wrote:
>> Szentirmai Gergely wrote:
>>> Does anybody has a estimation about the stack usage of pintf stuff? [...]
>>> As a summary, I would have to avoid the usage of any printf if I'm short
>>> of memory?
>> printf (or, more precisely, the actual format conversion in vfnprintf) is
>> really quite a complicated function. This regularly bites people on limited
>> targets; sometimes simply using printf is enough to cause your application
>> to fail to link because it won't fit into RAM.
>>
>> If you don't need to print out floating point numbers, you might save a
>> little code size by disabling that support in your eCos config. Otherwise,
>> puts and putc are pretty lean and mean - you could save a lot of code and
>> stack if you can avoid printf in your application.
> 
> Good points, but 'diag_printf()' is already quite stripped; no floating point.
> 

Thank you for your suggestions. I'll keep them in my mind.

Best wishes!
Gergely

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss