This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001253] Kernel tests on small memory targets


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]