[Bug 1001253] New: Kernel tests on small memory targets

[Bug 1001253] New: Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

           Summary: Kernel tests on small memory targets
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Other
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ilijak@siva.com.mk
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1269)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1269)
tm_basic.cxx

Some kernel tests have execution or compilation problems when applied on
targets with small RAM (example 32Kib LPC-1766-STK). Submitted patches provide
for application of these tests on devices with 32 KiB RAM. They have been
tested on LPC-1766-STK with kernel template.

Dependent on behavior and proposed solution (patch) I have sorted the problems
in 3 groups:

1. tm_basic

   behaviour: Compiles, but hangs during execution.

   cause: dependent on system RAM amount, array is defined for NTEST_THREADS
threads. If RAM is small enough (such as 32KiB) this can be 1 which is in
conflict with some tests that employ 2 threads.

   proposal: At least 2 thread members are enforced. Compiles and executes
complete test on target with 32KiB. For lower memory devices ld should report
error.

2. bin_sem2.cxx kmutex4 timeslice2 mutex3 timeslice kmutex3 thread_gdb

   behavior: ld complains for not enough memory.

   proposal: Dependent on system RAM tests are generated with less threads. For
"large" systems number of threads remains as before.

2. fptests 

   behavior: Linker complains for not enough memory.

   proposal (workaround): In order to enable error free compilation of kernel
tests this program is modified so it is compiled wihout threads. On execution a
message is printed: "This platform doesn't have enough RAM to run fptest.".

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:53:42 BST ---
Created an attachment (id=1270)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1270)
kmutex3.c

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:55:08 BST ---
Created an attachment (id=1272)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1272)
mutex3.cxx

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:54:20 BST ---
Created an attachment (id=1271)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1271)
kmutex4.c

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:56:02 BST ---
Created an attachment (id=1273)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1273)
thread_gdb.c

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #5 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:57:00 BST ---
Created an attachment (id=1274)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1274)
timeslice.c

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:57:36 BST ---
Created an attachment (id=1275)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1275)
timeslice2.c

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:58:31 BST ---
Created an attachment (id=1276)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1276)
fptests.c

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 15:00:10 BST ---
Created an attachment (id=1277)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1277)
bin_sem2.cxx

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1277|0                           |1
        is obsolete|                            |

--- Comment #9 from Ilija Kocho <ilijak@siva.com.mk> 2011-06-02 20:06:14 BST ---
Created an attachment (id=1278)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1278)
bin_sem2.cxx

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #10 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-02 10:14:31 BST ---
Hi Ilija,

First, thank you for your tests.

But, I have a doubt about your workaround. What will happen if someone
will try to manage the kernel tests for 16K or 48K targets? Of course,
it would be great if those predefined values (NTHREADS, PHILOSOPHERS,
etc.) were CDLized, but, in such a case a user must have an expert
knowledges in eCos kernel internals to manage predefined values in eCos
configtool, otherwise, I afraid we will get more reports from newbies
that kernel tests do hang during its runs.  Well, it is my view only.

I think that it would be better to have a way to manage a set of the
kernel tests, but, unfortunately, CDL CYGPKG_KERNEL_TESTS option is
*calculated* thing. I think that we would s/calculated/default_value/
for it and then low memory footprint targets will get a way to reduce
the set of the kernel tests. I mean

  cdl_option CYGPKG_KERNEL_TESTS {
      display "Kernel tests"
      flavor  data
      no_define
      # s/calculated/default_value/
      default_value {
        ...
      }
  }

and on the target's side (target.cdl) to have something like

  # This option would be a component with a set of the same
  # per-package options
  cdl_option CYGBLD_TARGET_TESTS_QUARANTINE {
      active_if CYGPKG_KERNEL
      default_value 1
      requires { !is_substr(CYGPKG_KERNEL_TESTS, " tests/tm_basic") }
          ...
      requires { !is_substr(CYGPKG_KERNEL_TESTS, " tests/fptest") }
  }

Well, perhaps, I'm totally wrong here. Really, it's cool to run 'tm_basic'
test on 32K targets, but, I would not want to see another set of predefined
limits (your 32K-limits) in the test's sources. It seems for me we need
in more elegant way to manage the issue if that is possible at all.

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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-02 22:31:30 BST ---
(In reply to comment #10)

Sergei

Thanks for your comments.

I would consider all groups as defined in comment #0 separately:

Note. In following text, I am deliberately placing 3. before 2. since numbers
are references to respective groups in comment #0.

    1. tm_basic - is good as it is since 2 tasks as a minimum is a must [for(i
= 0;  i < 2;  i++) loops]. Number 2 is only enforced if the macro NTEST_THREADS
(now __NTEST_THREADS) calculates < 2. If memory is too small than linker shall
raise an error and that means that this test can not be performed on that
configuration.

    3. fptests - the program as it is at present, would need major rework (if
ever possible) in order to make it work on little memory. That's the reason why
I have proposed a workaround that deliberately "gives up" if memory is too
little.

    2. For other tests, it would be useful to consider some finer / more
intelligent behavior. I am not excluding CDL, but maybe some macro calculations
would do. Please note that below 32KiB we are very close to the limit where the
tests wouldn't compile at all, so we need to cover few possibilities (if any).
I am now preoccupied with a contribution I consider more important, but when
able I will check 48 KiB and 16 KiB.

Ilija

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #12 from John Dallaway <john@dallaway.org.uk> 2011-07-03 07:26:07 BST ---
(In reply to comment #10)

Sergei wrote:

> Well, perhaps, I'm totally wrong here. Really, it's cool to run 'tm_basic'
> test on 32K targets, but, I would not want to see another set of predefined
> limits (your 32K-limits) in the test's sources. It seems for me we need
> in more elegant way to manage the issue if that is possible at all.

Sergei, I do agree that a programmatic calculation of memory resources for
these tests would be ideal. However, very few people will be attempting to use
the eCos kernel with 16KiB RAM.

I think Ilija's patches are a genuinely useful step forward from where we are
now and would be inclined to accept them. They do not prevent a programmatic
calculation in the future.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-03 16:10:29 BST ---
Ijija, John, thank you for your comments and opinions. Unfortunately, I
cannot reply on the thread just now, as I am almost AFK. CYA.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #15 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-04 20:57:26 BST ---
(In reply to comment #14)

> 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? 

I tested that a bit.  Well, it was possible to get more resources for
the test tuning the dividers, but, by my opinion that is a something
misplaced, I mean to add new ifdefs for xx_Kib targets in the kernel
tests. May be it's better to add stub inclusions for some critical
tests, e.g.

#ifdef CYGPKG_KERNEL_TESTS_tm_basic_LIMITS
#include CYGPKG_KERNEL_TESTS_tm_basic_LIMITS
#endif

etc.

Then any HAL designer would overwrite those defaults after a testing the
new values on real hardware.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #16 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-05 09:14:56 BST ---
(In reply to comment #14)
> 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.

I haven't tried SRAM startup on 32K. However, I did play with stacks (IRQ and
threads) sizes and I did gain more threads, but when it came to preparation of
the patches I tried to make them non-intrusive for both large and small memory
targets - to run tests with default settings.

I am aware that there are many ways to optimize tests for memory but again, the
question is how many new targets shall we gain. IMO small target treatment does
not involve only the tests but also other optimizations such as dedicated small
memory template(s). IRC we once came to small targets question during review of
Stellaris port...

CU.

Ilija

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #17 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-05 11:01:02 BST ---
Ok, back to `tm_basic`

(In reply to comment #11)

> 1. tm_basic - is good as it is since 2 tasks as a minimum is a must
> [for(i = 0;  i < 2;  i++) loops]. Number 2 is only enforced if the
> macro NTEST_THREADS (now __NTEST_THREADS) calculates < 2. If memory is
> too small than linker shall raise an error and that means that this
> test can not be performed on that configuration.

Then it seems for me this will be more clear

#ifndef max
#define max(X,Y) ((X) > (Y) ? (X) : (Y))
#endif

#define N_THREADS_MAX  ((CYGMEM_REGION_ram_SIZE/16)/CYG_THREAD_OVERHEAD)
#define NTEST_THREADS  max(2, N_THREADS_MAX)

and it's all. I dislike to add that `NTEST_2_THR` (may be N_THREADS_MIN)
and I've seen no sense to tweak those for loops. What do you think?

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #18 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-05 11:16:17 BST ---
(In reply to comment #17)

s/N_THREADS_MAX/N_THREADS_AVAIL/

it's better.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #19 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-05 11:52:20 BST ---
(In reply to comment #11)

> 3. fptests - the program as it is at present, would need major rework
> (if ever possible) in order to make it work on little memory. That's
> the reason why I have proposed a workaround that deliberately "gives
> up" if memory is too little.

IMO (for now) it's better to use a standard eCos catch there:

  #ifndef NA_MSG

   ...

  #else /* ifndef NA_MSG */

  externC void
  cyg_start( void )
  {
      CYG_TEST_INIT();
      CYG_TEST_NA(NA_MSG);
  }
  #endif

instead of fixing NTHREADS value.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #20 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-05 15:43:55 BST ---
(In reply to comment #17)
> Ok, back to `tm_basic`
> 
> (In reply to comment #11)
> 
> > 1. tm_basic - is good as it is since 2 tasks as a minimum is a must
> > [for(i = 0;  i < 2;  i++) loops]. Number 2 is only enforced if the
> > macro NTEST_THREADS (now __NTEST_THREADS) calculates < 2. If memory is
> > too small than linker shall raise an error and that means that this
> > test can not be performed on that configuration.
> 
> Then it seems for me this will be more clear

To me both are obvious. I think it is not necessary explaining max to eCos
programmer :)

> 
> #ifndef max
> #define max(X,Y) ((X) > (Y) ? (X) : (Y))
> #endif
> 
> #define N_THREADS_MAX  ((CYGMEM_REGION_ram_SIZE/16)/CYG_THREAD_OVERHEAD)
> #define NTEST_THREADS  max(2, N_THREADS_MAX)

I would change N_THREADS_MAX to somethine other as upper expression suggests it
needn't be the Max. Maybe N_THREADS_EST (estimated) or N_THREADS_MAX_EST.

> 
> and it's all. I dislike to add that `NTEST_2_THR` (may be N_THREADS_MIN)
> and I've seen no sense to tweak those for loops. What do you think?

NTEST_2_THR was intended to mean constant 2. If you don't like it we can keep
the original (bare 2).

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-05 16:09:16 BST ---
(In reply to comment #19)
> (In reply to comment #11)
> 
> > 3. fptests - the program as it is at present, would need major rework
> > (if ever possible) in order to make it work on little memory. That's
> > the reason why I have proposed a workaround that deliberately "gives
> > up" if memory is too little.
> 
> IMO (for now) it's better to use a standard eCos catch there:
> 
>   #ifndef NA_MSG
> 
>    ...
> 
>   #else /* ifndef NA_MSG */
> 
>   externC void
>   cyg_start( void )
>   {
>       CYG_TEST_INIT();
>       CYG_TEST_NA(NA_MSG);
>   }
>   #endif
> 
> instead of fixing NTHREADS value.

Elegant. We can use NA_MSG.

In addition it would be good to test for 48 KiB (I have tested 64 KiB -
passed).

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #22 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-05 17:09:37 BST ---
(In reply to comment #20)

> To me both are obvious. I think it is not necessary explaining max to eCos
> programmer :)
> 
> > #ifndef max
> > #define max(X,Y) ((X) > (Y) ? (X) : (Y))
> > #endif

No, this is not explanation :-) This is a *reminder* that such a check and
definition should be *above* its usage. FYI: there is the same definition
for min() in the test.

> > #define N_THREADS_MAX  ((CYGMEM_REGION_ram_SIZE/16)/CYG_THREAD_OVERHEAD)
> > #define NTEST_THREADS  max(2, N_THREADS_MAX)
> 
> I would change N_THREADS_MAX to somethine other as upper expression
> suggests it needn't be the Max. Maybe N_THREADS_EST (estimated) or
> N_THREADS_MAX_EST.

Then I did correct myself (comment 18) and offer N_THREADS_AVAIL for
naming.

> > and it's all. I dislike to add that `NTEST_2_THR` (may be
> > N_THREADS_MIN) and I've seen no sense to tweak those for loops. What
> > do you think?
> 
> NTEST_2_THR was intended to mean constant 2. If you don't like it we
> can keep the original (bare 2).

As for me "bare 2" is preferred there.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-05 18:25:26 BST ---
(In reply to comment #22)
> (In reply to comment #20)
> 
> > To me both are obvious. I think it is not necessary explaining max to eCos
> > programmer :)
> > 
> > > #ifndef max
> > > #define max(X,Y) ((X) > (Y) ? (X) : (Y))
> > > #endif
> 
> No, this is not explanation :-) This is a *reminder* that such a check and
> definition should be *above* its usage. FYI: there is the same definition
> for min() in the test.
> 

I meant complete max() definition. Kind of explains what

#define NTEST_THREADS \
  (__NTEST_THREADS >= NTEST_2_THR ? __NTEST_THREADS : NTEST_2_THR)

does.

> Then I did correct myself (comment 18) and offer N_THREADS_AVAIL for
> naming.

Yeah, i saw it but too late, sorry.

> > 
> > NTEST_2_THR was intended to mean constant 2. If you don't like it we
> > can keep the original (bare 2).
> 
> As for me "bare 2" is preferred there.

Set.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1269|0                           |1
        is obsolete|                            |

--- Comment #24 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 09:28:25 BST ---
Created an attachment (id=1305)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1305)
given a chance to run tm_basic on 32Kib targets

Two-lines patch (obsoletes attachment 1269), added ChangeLog entry. Ilija, can
you, please, test it on your target?

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #25 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 10:07:07 BST ---
(In reply to comment #11)

Ilija wrote:

> 2. For other tests, it would be useful to consider some finer / more
> intelligent behavior. I am not excluding CDL, but maybe some macro
> calculations would do. Please note that below 32KiB we are very close
> to the limit where the tests wouldn't compile at all, so we need to
> cover few possibilities (if any). I am now preoccupied with a
> contribution I consider more important, but when able I will check 48
> KiB and 16 KiB.

Ilija, please, forget 16Kib :-) It was unresonable request from me. Now
I agree with John:

> I think Ilija's patches are a genuinely useful step forward from where
> we are now and would be inclined to accept them. They do not prevent a
> programmatic calculation in the future.

So, we can assume that 32Kib is a litmus test. And I hope that no one
would argu against accepting you patches by point 2.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #26 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 13:01:06 BST ---
(In reply to comment #19)

> > 3. fptests - the program as it is at present, would need major rework
> > (if ever possible) in order to make it work on little memory. That's
> > the reason why I have proposed a workaround that deliberately "gives
> > up" if memory is too little.
> 
> IMO (for now) it's better to use a standard eCos catch there:
> 
>   #ifndef NA_MSG

Ilija, there is the same check there:

#if defined(CYGFUN_KERNEL_API_C) &&             \                               
    defined(CYGSEM_KERNEL_SCHED_MLQUEUE) &&     \                               
    (CYGNUM_KERNEL_SCHED_PRIORITIES > 12)

and you would expand the check to verify CYGMEM_REGION_ram_SIZE.

I seemed for me SIZE >= 64 Kib is sufficient condition for the fptest.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #27 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 15:29:57 BST ---
Ilija, and the last minor note. IMHO, in those other diffs for kernel
tests is preffered to use

#if (CYGMEM_REGION_ram_SIZE <= 32768)

check instead of

#if defined(CYGMEM_REGION_ram_SIZE) && (CYGMEM_REGION_ram_SIZE <= 32768)

The checks are the same here, but, the first check makes compiler to
generate a warning if CYGMEM_REGION_ram_SIZE is not defined:

*:warning: "CYGMEM_REGION_ram_SIZE" is not defined

if we use ``-Wundef`` flag (and we use it in eCos) and (IMO) it's good
to know about undef, and with the second check compiler won't disturb
us.

However, this is a matter of taste. The choise is yours.

Then we would add

#define TINY_SYS (CYGMEM_REGION_ram_SIZE <= 32768)
#define PONY_SYS (!TINY_SYS && (CYGMEM_REGION_ram_SIZE <= 49152))
#define BABY_SYS (!TINY_SYS && !PONY_SYS && (CYGMEM_REGION_ram_SIZE <= 65536))

and check if TINY_SYS ... elif PONY_SYS ... :-)

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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #28 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-06 20:00:11 BST ---
(In reply to comment #24 till comment #27)
> Created an attachment (id=1305)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1305) [details]
> given a chance to run tm_basic on 32Kib targets
> 
> Two-lines patch (obsoletes attachment 1269 [details]), added ChangeLog entry. Ilija, can
> you, please, test it on your target?

Tkank you Sergei. I will take tests, only I am little-bit saturated with jobs
till end of this week. I hope for weekend or begin of next week.

CU
Ilija

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #29 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 20:29:50 BST ---
(In reply to comment #28)

> > Two-lines patch (obsoletes attachment 1269 [details]), added
> > ChangeLog entry. Ilija, can you, please, test it on your target?
> 
> Tkank you Sergei. I will take tests, only I am little-bit saturated
> with jobs till end of this week. I hope for weekend or begin of next
> week.

No problem at all, thank you.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1276|0                           |1
        is obsolete|                            |

--- Comment #30 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:01:42 BST ---
Created an attachment (id=1308)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1308)
fptest.c_110709.diff

(In reply to comment #26)

Sergei

> 
> Ilija, there is the same check there:
> 
> #if defined(CYGFUN_KERNEL_API_C) &&             \
>     defined(CYGSEM_KERNEL_SCHED_MLQUEUE) &&     \
>     (CYGNUM_KERNEL_SCHED_PRIORITIES > 12)

Here is fptest patch attached. I tested (simulated) with 48 KiB RAM (with
default stack of 4 KiB) so I have set threshold accordingly.

(In reply to comment #24)
>Ilija, can
> you, please, test it on your target?

I did tests with tm_basic. Compiles and executes OK. Thank you for the patch,
Sergei.

Ilija

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1273|0                           |1
        is obsolete|                            |

--- Comment #31 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:14:52 BST ---
Created an attachment (id=1309)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1309)
thread_gdb.c_110709 with test for 32KiB and 48KiB

(In reply to comment #27)
> Ilija, and the last minor note. IMHO, in those other diffs for kernel
> tests is preffered to use
> 
> #if (CYGMEM_REGION_ram_SIZE <= 32768)
> 
> check instead of
> 
> #if defined(CYGMEM_REGION_ram_SIZE) && (CYGMEM_REGION_ram_SIZE <= 32768)
> 

Sergei, thank you for this remark, in this case we would like warnings indeed.
I also fixed thread_gdb for 48KiB RAM (other programs compiled without).

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1270|0                           |1
        is obsolete|                            |

--- Comment #32 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:16:53 BST ---
Created an attachment (id=1310)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1310)
kmutex3.c_110709.diff

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1271|0                           |1
        is obsolete|                            |

--- Comment #33 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:18:19 BST ---
Created an attachment (id=1311)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1311)
kmutex4.c_110709.diff

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1272|0                           |1
        is obsolete|                            |

--- Comment #34 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:19:48 BST ---
Created an attachment (id=1312)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1312)
mutex3.cxx_110709.diff

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1274|0                           |1
        is obsolete|                            |

--- Comment #35 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:20:32 BST ---
Created an attachment (id=1313)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1313)
timeslice.c_110709.diff

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1275|0                           |1
        is obsolete|                            |

--- Comment #36 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:21:26 BST ---
Created an attachment (id=1314)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1314)
timeslice2.c_110709.diff

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1278|0                           |1
        is obsolete|                            |

--- Comment #37 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:24:51 BST ---
Created an attachment (id=1315)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1315)
bin_sem2.cxx_110709.diff

I wasn't entirely correct in comment #31. :( bin_sem2 also comes with test for
48KiB RAM.

Ilija

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #38 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-09 20:09:20 BST ---
Hi

Ilija, thank you for your time, testing and calibration. Ilija, I plan
only to sync your check in fptest.c and an output in TEST_NA printing.
IMHO, the parts should be equal and it's even good to know about that
decrement in 4096 bytes (no need to repost the patch). Also, it seems
for me it's better to have one ChangeLog record for all patches and to
refer on this bug report (I'll add it).

And if no one has a different opinion from below (I appealed :)

John wrote:

> I think Ilija's patches are a genuinely useful step forward from where
> we are now and would be inclined to accept them. They do not prevent a
> programmatic calculation in the future.

I would like check-in Ilija's patches.

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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #39 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-10 17:13:54 BST ---
Checked-in.

Ilija, thank you for your contribution to eCos, also for patience and
persistence. As always thanks to John for his expertise and opinion.

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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #40 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-10 19:12:25 BST ---
(In reply to comment #39)
> Checked-in.
> 
> Ilija, thank you for your contribution to eCos, also for patience and
> persistence. As always thanks to John for his expertise and opinion.
> 
> Sergei

Sergei, John, Thank you for review and efforts.

Ilija

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #41 from Ilija Kocho <ilijak@siva.com.mk> 2011-08-25 09:27:08 BST ---
As checked in CVS.

-- 
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.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #41 from Ilija Kocho <ilijak@siva.com.mk> 2011-08-25 09:27:08 BST ---
As checked in CVS.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #40 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-10 19:12:25 BST ---
(In reply to comment #39)
> Checked-in.
> 
> Ilija, thank you for your contribution to eCos, also for patience and
> persistence. As always thanks to John for his expertise and opinion.
> 
> Sergei

Sergei, John, Thank you for review and efforts.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #39 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-10 17:13:54 BST ---
Checked-in.

Ilija, thank you for your contribution to eCos, also for patience and
persistence. As always thanks to John for his expertise and opinion.

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #38 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-09 20:09:20 BST ---
Hi

Ilija, thank you for your time, testing and calibration. Ilija, I plan
only to sync your check in fptest.c and an output in TEST_NA printing.
IMHO, the parts should be equal and it's even good to know about that
decrement in 4096 bytes (no need to repost the patch). Also, it seems
for me it's better to have one ChangeLog record for all patches and to
refer on this bug report (I'll add it).

And if no one has a different opinion from below (I appealed :)

John wrote:

> I think Ilija's patches are a genuinely useful step forward from where
> we are now and would be inclined to accept them. They do not prevent a
> programmatic calculation in the future.

I would like check-in Ilija's patches.

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1278|0                           |1
        is obsolete|                            |

--- Comment #37 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:24:51 BST ---
Created an attachment (id=1315)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1315)
bin_sem2.cxx_110709.diff

I wasn't entirely correct in comment #31. :( bin_sem2 also comes with test for
48KiB RAM.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1275|0                           |1
        is obsolete|                            |

--- Comment #36 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:21:26 BST ---
Created an attachment (id=1314)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1314)
timeslice2.c_110709.diff

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1274|0                           |1
        is obsolete|                            |

--- Comment #35 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:20:32 BST ---
Created an attachment (id=1313)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1313)
timeslice.c_110709.diff

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1272|0                           |1
        is obsolete|                            |

--- Comment #34 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:19:48 BST ---
Created an attachment (id=1312)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1312)
mutex3.cxx_110709.diff

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1271|0                           |1
        is obsolete|                            |

--- Comment #33 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:18:19 BST ---
Created an attachment (id=1311)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1311)
kmutex4.c_110709.diff

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1270|0                           |1
        is obsolete|                            |

--- Comment #32 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:16:53 BST ---
Created an attachment (id=1310)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1310)
kmutex3.c_110709.diff

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1273|0                           |1
        is obsolete|                            |

--- Comment #31 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:14:52 BST ---
Created an attachment (id=1309)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1309)
thread_gdb.c_110709 with test for 32KiB and 48KiB

(In reply to comment #27)
> Ilija, and the last minor note. IMHO, in those other diffs for kernel
> tests is preffered to use
> 
> #if (CYGMEM_REGION_ram_SIZE <= 32768)
> 
> check instead of
> 
> #if defined(CYGMEM_REGION_ram_SIZE) && (CYGMEM_REGION_ram_SIZE <= 32768)
> 

Sergei, thank you for this remark, in this case we would like warnings indeed.
I also fixed thread_gdb for 48KiB RAM (other programs compiled without).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1276|0                           |1
        is obsolete|                            |

--- Comment #30 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-09 18:01:42 BST ---
Created an attachment (id=1308)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1308)
fptest.c_110709.diff

(In reply to comment #26)

Sergei

> 
> Ilija, there is the same check there:
> 
> #if defined(CYGFUN_KERNEL_API_C) &&             \
>     defined(CYGSEM_KERNEL_SCHED_MLQUEUE) &&     \
>     (CYGNUM_KERNEL_SCHED_PRIORITIES > 12)

Here is fptest patch attached. I tested (simulated) with 48 KiB RAM (with
default stack of 4 KiB) so I have set threshold accordingly.

(In reply to comment #24)
>Ilija, can
> you, please, test it on your target?

I did tests with tm_basic. Compiles and executes OK. Thank you for the patch,
Sergei.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #29 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 20:29:50 BST ---
(In reply to comment #28)

> > Two-lines patch (obsoletes attachment 1269 [details]), added
> > ChangeLog entry. Ilija, can you, please, test it on your target?
> 
> Tkank you Sergei. I will take tests, only I am little-bit saturated
> with jobs till end of this week. I hope for weekend or begin of next
> week.

No problem at all, thank you.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #28 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-06 20:00:11 BST ---
(In reply to comment #24 till comment #27)
> Created an attachment (id=1305)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1305) [details]
> given a chance to run tm_basic on 32Kib targets
> 
> Two-lines patch (obsoletes attachment 1269 [details]), added ChangeLog entry. Ilija, can
> you, please, test it on your target?

Tkank you Sergei. I will take tests, only I am little-bit saturated with jobs
till end of this week. I hope for weekend or begin of next week.

CU
Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #27 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 15:29:57 BST ---
Ilija, and the last minor note. IMHO, in those other diffs for kernel
tests is preffered to use

#if (CYGMEM_REGION_ram_SIZE <= 32768)

check instead of

#if defined(CYGMEM_REGION_ram_SIZE) && (CYGMEM_REGION_ram_SIZE <= 32768)

The checks are the same here, but, the first check makes compiler to
generate a warning if CYGMEM_REGION_ram_SIZE is not defined:

*:warning: "CYGMEM_REGION_ram_SIZE" is not defined

if we use ``-Wundef`` flag (and we use it in eCos) and (IMO) it's good
to know about undef, and with the second check compiler won't disturb
us.

However, this is a matter of taste. The choise is yours.

Then we would add

#define TINY_SYS (CYGMEM_REGION_ram_SIZE <= 32768)
#define PONY_SYS (!TINY_SYS && (CYGMEM_REGION_ram_SIZE <= 49152))
#define BABY_SYS (!TINY_SYS && !PONY_SYS && (CYGMEM_REGION_ram_SIZE <= 65536))

and check if TINY_SYS ... elif PONY_SYS ... :-)

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #26 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 13:01:06 BST ---
(In reply to comment #19)

> > 3. fptests - the program as it is at present, would need major rework
> > (if ever possible) in order to make it work on little memory. That's
> > the reason why I have proposed a workaround that deliberately "gives
> > up" if memory is too little.
> 
> IMO (for now) it's better to use a standard eCos catch there:
> 
>   #ifndef NA_MSG

Ilija, there is the same check there:

#if defined(CYGFUN_KERNEL_API_C) &&             \                               
    defined(CYGSEM_KERNEL_SCHED_MLQUEUE) &&     \                               
    (CYGNUM_KERNEL_SCHED_PRIORITIES > 12)

and you would expand the check to verify CYGMEM_REGION_ram_SIZE.

I seemed for me SIZE >= 64 Kib is sufficient condition for the fptest.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #25 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 10:07:07 BST ---
(In reply to comment #11)

Ilija wrote:

> 2. For other tests, it would be useful to consider some finer / more
> intelligent behavior. I am not excluding CDL, but maybe some macro
> calculations would do. Please note that below 32KiB we are very close
> to the limit where the tests wouldn't compile at all, so we need to
> cover few possibilities (if any). I am now preoccupied with a
> contribution I consider more important, but when able I will check 48
> KiB and 16 KiB.

Ilija, please, forget 16Kib :-) It was unresonable request from me. Now
I agree with John:

> I think Ilija's patches are a genuinely useful step forward from where
> we are now and would be inclined to accept them. They do not prevent a
> programmatic calculation in the future.

So, we can assume that 32Kib is a litmus test. And I hope that no one
would argu against accepting you patches by point 2.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1269|0                           |1
        is obsolete|                            |

--- Comment #24 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-06 09:28:25 BST ---
Created an attachment (id=1305)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1305)
given a chance to run tm_basic on 32Kib targets

Two-lines patch (obsoletes attachment 1269), added ChangeLog entry. Ilija, can
you, please, test it on your target?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-05 18:25:26 BST ---
(In reply to comment #22)
> (In reply to comment #20)
> 
> > To me both are obvious. I think it is not necessary explaining max to eCos
> > programmer :)
> > 
> > > #ifndef max
> > > #define max(X,Y) ((X) > (Y) ? (X) : (Y))
> > > #endif
> 
> No, this is not explanation :-) This is a *reminder* that such a check and
> definition should be *above* its usage. FYI: there is the same definition
> for min() in the test.
> 

I meant complete max() definition. Kind of explains what

#define NTEST_THREADS \
  (__NTEST_THREADS >= NTEST_2_THR ? __NTEST_THREADS : NTEST_2_THR)

does.

> Then I did correct myself (comment 18) and offer N_THREADS_AVAIL for
> naming.

Yeah, i saw it but too late, sorry.

> > 
> > NTEST_2_THR was intended to mean constant 2. If you don't like it we
> > can keep the original (bare 2).
> 
> As for me "bare 2" is preferred there.

Set.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #22 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-05 17:09:37 BST ---
(In reply to comment #20)

> To me both are obvious. I think it is not necessary explaining max to eCos
> programmer :)
> 
> > #ifndef max
> > #define max(X,Y) ((X) > (Y) ? (X) : (Y))
> > #endif

No, this is not explanation :-) This is a *reminder* that such a check and
definition should be *above* its usage. FYI: there is the same definition
for min() in the test.

> > #define N_THREADS_MAX  ((CYGMEM_REGION_ram_SIZE/16)/CYG_THREAD_OVERHEAD)
> > #define NTEST_THREADS  max(2, N_THREADS_MAX)
> 
> I would change N_THREADS_MAX to somethine other as upper expression
> suggests it needn't be the Max. Maybe N_THREADS_EST (estimated) or
> N_THREADS_MAX_EST.

Then I did correct myself (comment 18) and offer N_THREADS_AVAIL for
naming.

> > and it's all. I dislike to add that `NTEST_2_THR` (may be
> > N_THREADS_MIN) and I've seen no sense to tweak those for loops. What
> > do you think?
> 
> NTEST_2_THR was intended to mean constant 2. If you don't like it we
> can keep the original (bare 2).

As for me "bare 2" is preferred there.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-05 16:09:16 BST ---
(In reply to comment #19)
> (In reply to comment #11)
> 
> > 3. fptests - the program as it is at present, would need major rework
> > (if ever possible) in order to make it work on little memory. That's
> > the reason why I have proposed a workaround that deliberately "gives
> > up" if memory is too little.
> 
> IMO (for now) it's better to use a standard eCos catch there:
> 
>   #ifndef NA_MSG
> 
>    ...
> 
>   #else /* ifndef NA_MSG */
> 
>   externC void
>   cyg_start( void )
>   {
>       CYG_TEST_INIT();
>       CYG_TEST_NA(NA_MSG);
>   }
>   #endif
> 
> instead of fixing NTHREADS value.

Elegant. We can use NA_MSG.

In addition it would be good to test for 48 KiB (I have tested 64 KiB -
passed).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #20 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-05 15:43:55 BST ---
(In reply to comment #17)
> Ok, back to `tm_basic`
> 
> (In reply to comment #11)
> 
> > 1. tm_basic - is good as it is since 2 tasks as a minimum is a must
> > [for(i = 0;  i < 2;  i++) loops]. Number 2 is only enforced if the
> > macro NTEST_THREADS (now __NTEST_THREADS) calculates < 2. If memory is
> > too small than linker shall raise an error and that means that this
> > test can not be performed on that configuration.
> 
> Then it seems for me this will be more clear

To me both are obvious. I think it is not necessary explaining max to eCos
programmer :)

> 
> #ifndef max
> #define max(X,Y) ((X) > (Y) ? (X) : (Y))
> #endif
> 
> #define N_THREADS_MAX  ((CYGMEM_REGION_ram_SIZE/16)/CYG_THREAD_OVERHEAD)
> #define NTEST_THREADS  max(2, N_THREADS_MAX)

I would change N_THREADS_MAX to somethine other as upper expression suggests it
needn't be the Max. Maybe N_THREADS_EST (estimated) or N_THREADS_MAX_EST.

> 
> and it's all. I dislike to add that `NTEST_2_THR` (may be N_THREADS_MIN)
> and I've seen no sense to tweak those for loops. What do you think?

NTEST_2_THR was intended to mean constant 2. If you don't like it we can keep
the original (bare 2).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #19 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-05 11:52:20 BST ---
(In reply to comment #11)

> 3. fptests - the program as it is at present, would need major rework
> (if ever possible) in order to make it work on little memory. That's
> the reason why I have proposed a workaround that deliberately "gives
> up" if memory is too little.

IMO (for now) it's better to use a standard eCos catch there:

  #ifndef NA_MSG

   ...

  #else /* ifndef NA_MSG */

  externC void
  cyg_start( void )
  {
      CYG_TEST_INIT();
      CYG_TEST_NA(NA_MSG);
  }
  #endif

instead of fixing NTHREADS value.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #18 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-05 11:16:17 BST ---
(In reply to comment #17)

s/N_THREADS_MAX/N_THREADS_AVAIL/

it's better.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #17 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-05 11:01:02 BST ---
Ok, back to `tm_basic`

(In reply to comment #11)

> 1. tm_basic - is good as it is since 2 tasks as a minimum is a must
> [for(i = 0;  i < 2;  i++) loops]. Number 2 is only enforced if the
> macro NTEST_THREADS (now __NTEST_THREADS) calculates < 2. If memory is
> too small than linker shall raise an error and that means that this
> test can not be performed on that configuration.

Then it seems for me this will be more clear

#ifndef max
#define max(X,Y) ((X) > (Y) ? (X) : (Y))
#endif

#define N_THREADS_MAX  ((CYGMEM_REGION_ram_SIZE/16)/CYG_THREAD_OVERHEAD)
#define NTEST_THREADS  max(2, N_THREADS_MAX)

and it's all. I dislike to add that `NTEST_2_THR` (may be N_THREADS_MIN)
and I've seen no sense to tweak those for loops. What do you think?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #16 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-05 09:14:56 BST ---
(In reply to comment #14)
> 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.

I haven't tried SRAM startup on 32K. However, I did play with stacks (IRQ and
threads) sizes and I did gain more threads, but when it came to preparation of
the patches I tried to make them non-intrusive for both large and small memory
targets - to run tests with default settings.

I am aware that there are many ways to optimize tests for memory but again, the
question is how many new targets shall we gain. IMO small target treatment does
not involve only the tests but also other optimizations such as dedicated small
memory template(s). IRC we once came to small targets question during review of
Stellaris port...

CU.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #15 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-04 20:57:26 BST ---
(In reply to comment #14)

> 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? 

I tested that a bit.  Well, it was possible to get more resources for
the test tuning the dividers, but, by my opinion that is a something
misplaced, I mean to add new ifdefs for xx_Kib targets in the kernel
tests. May be it's better to add stub inclusions for some critical
tests, e.g.

#ifdef CYGPKG_KERNEL_TESTS_tm_basic_LIMITS
#include CYGPKG_KERNEL_TESTS_tm_basic_LIMITS
#endif

etc.

Then any HAL designer would overwrite those defaults after a testing the
new values on real hardware.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

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 the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-03 16:10:29 BST ---
Ijija, John, thank you for your comments and opinions. Unfortunately, I
cannot reply on the thread just now, as I am almost AFK. CYA.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #12 from John Dallaway <john@dallaway.org.uk> 2011-07-03 07:26:07 BST ---
(In reply to comment #10)

Sergei wrote:

> Well, perhaps, I'm totally wrong here. Really, it's cool to run 'tm_basic'
> test on 32K targets, but, I would not want to see another set of predefined
> limits (your 32K-limits) in the test's sources. It seems for me we need
> in more elegant way to manage the issue if that is possible at all.

Sergei, I do agree that a programmatic calculation of memory resources for
these tests would be ideal. However, very few people will be attempting to use
the eCos kernel with 16KiB RAM.

I think Ilija's patches are a genuinely useful step forward from where we are
now and would be inclined to accept them. They do not prevent a programmatic
calculation in the future.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2011-07-02 22:31:30 BST ---
(In reply to comment #10)

Sergei

Thanks for your comments.

I would consider all groups as defined in comment #0 separately:

Note. In following text, I am deliberately placing 3. before 2. since numbers
are references to respective groups in comment #0.

    1. tm_basic - is good as it is since 2 tasks as a minimum is a must [for(i
= 0;  i < 2;  i++) loops]. Number 2 is only enforced if the macro NTEST_THREADS
(now __NTEST_THREADS) calculates < 2. If memory is too small than linker shall
raise an error and that means that this test can not be performed on that
configuration.

    3. fptests - the program as it is at present, would need major rework (if
ever possible) in order to make it work on little memory. That's the reason why
I have proposed a workaround that deliberately "gives up" if memory is too
little.

    2. For other tests, it would be useful to consider some finer / more
intelligent behavior. I am not excluding CDL, but maybe some macro calculations
would do. Please note that below 32KiB we are very close to the limit where the
tests wouldn't compile at all, so we need to cover few possibilities (if any).
I am now preoccupied with a contribution I consider more important, but when
able I will check 48 KiB and 16 KiB.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #10 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-07-02 10:14:31 BST ---
Hi Ilija,

First, thank you for your tests.

But, I have a doubt about your workaround. What will happen if someone
will try to manage the kernel tests for 16K or 48K targets? Of course,
it would be great if those predefined values (NTHREADS, PHILOSOPHERS,
etc.) were CDLized, but, in such a case a user must have an expert
knowledges in eCos kernel internals to manage predefined values in eCos
configtool, otherwise, I afraid we will get more reports from newbies
that kernel tests do hang during its runs.  Well, it is my view only.

I think that it would be better to have a way to manage a set of the
kernel tests, but, unfortunately, CDL CYGPKG_KERNEL_TESTS option is
*calculated* thing. I think that we would s/calculated/default_value/
for it and then low memory footprint targets will get a way to reduce
the set of the kernel tests. I mean

  cdl_option CYGPKG_KERNEL_TESTS {
      display "Kernel tests"
      flavor  data
      no_define
      # s/calculated/default_value/
      default_value {
        ...
      }
  }

and on the target's side (target.cdl) to have something like

  # This option would be a component with a set of the same
  # per-package options
  cdl_option CYGBLD_TARGET_TESTS_QUARANTINE {
      active_if CYGPKG_KERNEL
      default_value 1
      requires { !is_substr(CYGPKG_KERNEL_TESTS, " tests/tm_basic") }
          ...
      requires { !is_substr(CYGPKG_KERNEL_TESTS, " tests/fptest") }
  }

Well, perhaps, I'm totally wrong here. Really, it's cool to run 'tm_basic'
test on 32K targets, but, I would not want to see another set of predefined
limits (your 32K-limits) in the test's sources. It seems for me we need
in more elegant way to manage the issue if that is possible at all.

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1277|0                           |1
        is obsolete|                            |

--- Comment #9 from Ilija Kocho <ilijak@siva.com.mk> 2011-06-02 20:06:14 BST ---
Created an attachment (id=1278)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1278)
bin_sem2.cxx

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 15:00:10 BST ---
Created an attachment (id=1277)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1277)
bin_sem2.cxx

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:58:31 BST ---
Created an attachment (id=1276)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1276)
fptests.c

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:57:36 BST ---
Created an attachment (id=1275)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1275)
timeslice2.c

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #5 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:57:00 BST ---
Created an attachment (id=1274)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1274)
timeslice.c

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:56:02 BST ---
Created an attachment (id=1273)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1273)
thread_gdb.c

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:54:20 BST ---
Created an attachment (id=1271)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1271)
kmutex4.c

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:55:08 BST ---
Created an attachment (id=1272)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1272)
mutex3.cxx

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001253] Kernel tests on small memory targets

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-31 14:53:42 BST ---
Created an attachment (id=1270)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1270)
kmutex3.c

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.