This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001253] Kernel tests on small memory targets
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Mon, 4 Jul 2011 11:10:48 +0100
- Subject: [Bug 1001253] Kernel tests on small memory targets
- Auto-submitted: auto-generated
- References: <bug-1001253-13@http.bugs.ecos.sourceware.org/>
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253
--- Comment #14 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-04 11:10:41 BST ---
Some thoughts on `tm_basic` limits. My first question, Ilija, did you
manage runs for CYG_HAL_STARTUP = RAM? I think you did not. You tried to
get at the least two running threads in `tm_basic` on 32K target. Where
can we find more resources? For tests I chose 64K target 'p2106' and
built ROM-able `tm_basic` test for it using *kernel* template. Let's
look
arm-eabi-size tm_basic
text data bss dec hex filename
47416 772 37768 85956 14fc4 tm_basic
and
arm-eabi-size tm_basic.o
text data bss dec hex filename
19072 0 30300 49372 c0dc tm_basic.o
Of course, my interest is .bss segment. So, eCos kernel, eCos infra,
default stacks eat about 8K of .bss and tm_basic eats 30K of .bss. Why I
waste other bytes? Once again I used kernel template and ROM startup for
the build.
There are a few dividers which limit .bss usage (those 16 and 24):
#define NTEST_THREADS ((CYGMEM_REGION_ram_SIZE/16)/CYG_THREAD_OVERHEAD)
...
#define NMBOXES ((CYGMEM_REGION_ram_SIZE/24)/CYG_MBOX_OVERHEAD)
When I summed all pieces, I've seen that limit for test resources is set
to 3/8, of RAM size, i.e. 24K for 64K targets (or 12K for 32K targets).
And I thought that the dividers would be more friendly and would depend
on CYG_HAL_STARTUP (may be on used template also) and, perhaps, we can
utilize more of RAM for the test then?
Yet another interesting output
arm-eabi-size -A kernel/current/tests/tm_basic.o | grep ^\.bss
The output is about 2 screens and I do not paste it here, but, Ilija,
you can see that there are more resources to graduate or to shrink, i.e.
we can tune not only NTEST_THREADS limit.
Well, all the above has not been tested yet on any real target (only
builds) and it is only my thoughts/guess. I have not 32K target. But it
seemed for me (may be I wrong) that "3/8" limit can be expanded a bit
for the ROM builds. My guess that 5/8 was reserved for worst conditions,
i.e. for .text, .data, .bss, .rodata, etc. for the most eCos templates
(default, net? all?) and RAM startups and it seems 3/8 limit was fine
graduated value for the most targets. Even if to expand 3/8 limit is a
bad idea, may be it has a sense to try to play with the divider's
values? For example, I tried to use "eight" divider for NTHREADS and I
utilized more of RAM and got more threads (well, may be the test will
hang, not tested):
arm-eabi-size tm_basic.o
text data bss dec hex filename
19020 0 34200 53220 cfe4 tm_basic.o
It's pity that I cannot test my guess on low memory footprint targets
Be continue.
Sergei
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.