Changes between Version 29 and Version 30 of Developer/SMP


Ignore:
Timestamp:
Jan 13, 2014, 4:07:48 PM (6 years ago)
Author:
Sh
Comment:

/* Testing */

Legend:

Unmodified
Added
Removed
Modified
  • Developer/SMP

    v29 v30  
    477477This scheme could be used for all architectures.  Further discussion is
    478478necessary.  An alternative to post-switch handlers is currently unknown.
    479 = = Thread Delete  ==
    480 
    481 =  === Status ====
     479=  Thread Delete  =
     480
     481==  Status  ==
    482482
    483483
    484484Deletion of threads is not implemented.
    485 
    486 ==== Future Directions ====
     485==  Future Directions  ==
    487486
    488487
     
    492491party.  On single processor configurations this was done with a hack that
    493492doesn't work on SMP.  See also [http://www.rtems.org/pipermail/rtems-devel/2013-July/003509.html Thread Life-Cycle Changes.]
    494 
    495 === Semaphores and Mutexes ===
    496 
    497 
    498 ==== Status ====
     493=  Semaphores and Mutexes  =
     494
     495==  Status  ==
    499496
    500497
     
    502499configurations this first acquires the Giant lock and then interrupts are
    503500disabled.
    504 
    505 ==== Future Directions ====
     501==  Future Directions  ==
    506502
    507503
    508504Use an ISR lock per object to improve the performance for uncontested
    509 operations.  See also [[#Giant Lock vs. Fine Grained Locking|Giant Lock vs. Fine Grained Locking]].
    510 
    511 == Implementation ==
    512 
    513 
    514 == Testing ==
    515 
    516 
    517 == References ==
     505operations.  See also [wiki:#Giant_Lock_vs._Fine_Grained_Locking Giant Lock vs. Fine Grained Locking].
     506=  Implementation  =
     507
     508=  Testing  =
     509
     510=  Overview  =
     511
     512
     513[http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]
     514will be used to implement the accepted changes and features.  New tests cases
     515will follow the patterns present in existing test cases of the RTEMS test
     516suite.  The RTEMS project has a script framework to run the RTEMS test suite.
     517This works best if the tests can run on a fast simulator.
     518=  Worst-Case Timings  =
     519
     520
     521The RTEMS test suite has some timing tests (testsuites/tmtests and testsuites/psxtmtests).  These tests yield only some sample timing values with no statistical significance.  For a real-time operating system reliable worst-case timing values of critical functions are interesting.  A presence of instruction and data caches must be taken into account.  Measurements for the worst-case timing should run in the following context
     522 *  instruction caches are invalidated,
     523 *  data caches are completely dirty with unrelated data, since in this case data for the section of interest must first evict dirty cache lines and then load the values from main memory,
     524 *  on SMP configurations all other processors should try to saturate the bus.
     525Timing values should be acquired multiple times to get a statistical significant value.
     526
     527Currently most operating system functions are monolithic global functions which can be only tested as a single unit.  This leads to very complex test setups since interrupts must be used to trigger different paths through these functions.  In order to implement fine grained locking large parts of core operating system functions must be restructured.  As part of this process the critical sections should be implemented as inline functions which can be tested independently.  All critical sections for a specific lock should be tested in isolation so that worst-case timing values can be determined.  Since all the core operating system functions are aggregations of critical sections it is possible to give worst-case timing estimates provided the worst-case timings are known each critical section on its own.
     528
     529It is not the goal of the project to characterise finely all RTEMS services in combination of the all possible load figures in the processors.  However, instrumentation of critical items such as SMP locks and interrupt disabling will allow collecting a good idea about the system behaviour when the system is stressed by all sorts of RTEMS tests, demonstrators and parallel library tests.
     530=  References  =
    518531
    519532