GitLab

Jan Kiszka authored Jun 22, 2018 and Philippe Gerum committed Jul 03, 2018

Enables compat-capable implementations of this extension.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Jan Kiszka authored Jun 22, 2018 and Philippe Gerum committed Jul 03, 2018

We want to pass the information "compat invocation" to the extension
signal_copyinfo as well and therefore need it in boolean form. To avoid
unneeded conversions, pass it as bool from the source to the sink.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Jan Kiszka authored Jun 22, 2018 and Philippe Gerum committed Jul 03, 2018

We will need it inside signal_wait. No functional changes.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

The node search and comparison function addresses are process-local in
essence, do not share them.

Since some changes in this recent API were required, the few existing
users were converted to use the new API in the process.

The tests exercizing the memory allocator may run for several minutes
each depending on the platform, in order to obtain reliable
performance figures. Reduce this amount of runtime for a basic
functional validation of those allocators.

Address the issue mentioned in [1] regarding the shared memory
allocator, using a variant of the McKusick scheme significantly
improving the performance figures, especially regarding memory release
operations.

As a by-product of this overhaul, the shared memory allocator can now
manage heaps up to (4GB - PAGE_SIZE).

[1] http://www.xenomai.org/pipermail/xenomai/2018-April/038883.html

So that we may have both coexisting in a single executable.

The powerpc64 architecture does not seem to have any active Xenomai
user, at least none who may be concerned enough to be willing to help
in maintaining this Xenomai port.

The blackfin architecture is not supported by the mainline kernel
anymore since 4.17, and no concerned user showed up, willing to help
in maintaining this Xenomai port.

Address the issue mentioned in [1] regarding the core (xnheap)
allocator, using a variant of the McKusick scheme significantly
improving the performance figures.

As a by-product of this overhaul, the core allocator can now manage
heaps up to (4GB - PAGE_SIZE).

The performance report log obtained by testing on imx6qp
is as follows:

== memcheck started
     seq_heap_size=2048k
     random_alloc_rounds=1024
     pattern_heap_size=128k
     pattern_check_rounds=128

[SEQUENTIAL ALLOC->FREE, ^2 BLOCK SIZES] ON 'xnheap'

HEAPSZ	test heap size
BLOCKSZ	tested block size
NRBLKS	number of blocks allocatable in heap
AVG-A	average time to allocate block (us)
AVG-F	average time to free block (us)
MAX-A	max time to allocate block (us)
MAX-F	max time to free block (us)
FLAGS	+shuffle: randomized free
    	+realloc: measure after initial alloc/free pass (hot heap)

sorted by: max alloc time
  HEAPSZ  BLOCKSZ   NRBLKS  AVG-A  AVG-F  MAX-A  MAX-F   FLAGS
   1024k       32    32768      0      0      8      6
   1024k       32    32768      0      0      7      2   +shuffle +realloc
   1024k       16    65536      0      0      7      2   +realloc
   1024k       16    65536      0      0      6      7   +shuffle +realloc
  ... (364 results following) ...

sorted by: max free time
  HEAPSZ  BLOCKSZ   NRBLKS  AVG-A  AVG-F  MAX-A  MAX-F   FLAGS
   1024k      128     8192      0      1      2      8
   1024k       16    65536      0      0      6      7   +shuffle +realloc
   1024k       32    32768      0      0      8      6
    512k       32    16384      0      0      5      6   +realloc
  ... (364 results following) ...

overall:
  worst alloc time: 8 (us)
  worst free time: 8 (us)
  average of max. alloc times: 1 (us)
  average of max. free times: 2 (us)
  average alloc time: 1 (us)
  average free time: 1 (us)

[SEQUENTIAL ALLOC->FREE, RANDOM BLOCK SIZES] ON 'xnheap'

HEAPSZ	test heap size
BLOCKSZ	tested block size
NRBLKS	number of blocks allocatable in heap
AVG-A	average time to allocate block (us)
AVG-F	average time to free block (us)
MAX-A	max time to allocate block (us)
MAX-F	max time to free block (us)
FLAGS	+shuffle: randomized free
    	+realloc: measure after initial alloc/free pass (hot heap)

sorted by: max alloc time
  HEAPSZ  BLOCKSZ   NRBLKS  AVG-A  AVG-F  MAX-A  MAX-F   FLAGS
    512k       17k      28      1      1      8      2   +shuffle
    512k       45k      11      1      1      7      2
   1024k       24    32768      0      0      7      6   +shuffle
    128k      820      128      1      1      6      2   +shuffle
  ... (32764 results following) ...

sorted by: max free time
  HEAPSZ  BLOCKSZ   NRBLKS  AVG-A  AVG-F  MAX-A  MAX-F   FLAGS
   1024k        3k     292      1      1      1      8   +shuffle
    256k      174     1024      1      1      1      6   +shuffle
   1024k       24    32768      0      0      7      6   +shuffle
     32k       12k       2      2      3      1      5
  ... (32764 results following) ...

overall:
  worst alloc time: 8 (us)
  worst free time: 8 (us)
  average of max. alloc times: 1 (us)
  average of max. free times: 1 (us)
  average alloc time: 1 (us)
  average free time: 1 (us)

[1] http://www.xenomai.org/pipermail/xenomai/2018-April/038883.html

Make HEAPMEM the default private memory allocator for real-time
configurations (cobalt || (mercury && non-debug)).

This setting can be reverted by passing --with-localmem=tlsf.

This is the umpteenth incarnation of the McKusick allocator, aimed at
replacing other allocators which have serious issues:

- TLSF is fast but not that good when it comes to memory overhead with
  small sizes (i.e. < 512 bytes) on 64bit.

- heapobj-pshared has decent overhead figures but may be insanely slow
  at deallocating blocks from large, hot heaps.

- the Cobalt core allocator is even worse than heapobj-pshared in
  deallocating blocks, although the system heap should be generally
  small enough not to trigger the most pathological cases in practice,
  hopefully. Nevertheless, the performances are unacceptable.

The original McKusick algorithm implements a quick fit allocation
scheme, based on bucket management of ^2-sized chunks, which
automatically switches to a page-based allocation method for blocks
larger than twice the base page size.

This variant maintains the free page list in AVL trees for fast
lookups of multi-page memory ranges, and pages holding bucketed memory
have a quick allocation bitmap to manage their blocks internally.

The current implementation can replace TLSF for delivering
process-local memory with similar performances but lesser overhead
with small sizes. Most importantly, a kernel variant of HEAPMEM should
replace the Cobalt core allocator. Likewise, heapobj-pshared which is
beyond repair should be replaced with a process-shareable variant as
well, assuming the average size and allocation patterns of real-time
objects are similar in all contexts.

Gilles Chanteperdrix authored Jul 12, 2016 and Philippe Gerum committed Jul 03, 2018

Make the AVL tree usable in shared memory when AVL_SHARED is defined
at build time, switching to offset-based memory references.

Gilles published this code in July 2016 as part of his personal
toolkit for hobby projects aka 'libchutils'.

Some architectures may define a secondary system call range for
internal operations, fix the consistency check not to warn about them.

Jan Kiszka authored May 02, 2018 and Philippe Gerum committed Jul 03, 2018

This stresses the case of fast-path mutex acquire plus pthread_cond_wait
with that mutex, which currently triggers a bug in xnsynch_release.

Along this, drop the HAVE_PTHREAD_MUTEXATTR_SETPROTOCOL conditional -
libboilerplate takes care of that.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Jan Kiszka authored May 02, 2018 and Philippe Gerum committed Jul 03, 2018

We must not try to drop the prio ceiling in the kernel if it wasn't
committed yet. That could easily happen when using a prio-ceiling mutex
to wait on a cond-var.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Norbert Lange authored Apr 25, 2018 and Philippe Gerum committed Jul 03, 2018

Signed-off-by: Norbert Lange <norbert.lange@andritz.com>

Jan Kiszka authored Apr 18, 2018 and Philippe Gerum committed Jul 03, 2018

Otherwise we first add the synch object to the new owner's boost list
before we remove it from the old one's, corrupting the list.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Jan Kiszka authored Apr 18, 2018 and Philippe Gerum committed Jul 03, 2018

This triggers a bug in the PP implementation.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>