[Xenomai-core] Extensible heaps - needed for the future?

[Xenomai-core] Extensible heaps - needed for the future?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Hi,

I noticed that xnhead_extend() is not used at the moment [1], thus the
whole extent management is redundent for now. Are there plans to use it
in the future? Should we keep this feature?

I'm asking as I still have the idea in my head of breaking up the heap
service and introducing a generic allocator interface to select
different heap allocators at compile time. So, should extensions be an
optional feature of an allocator?

Jan


[1]http://www.rts.uni-hannover.de/xenomai/lxr/ident?v=SVN-trunk;i=xnheap_extend

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Xenomai-core] Extensible heaps - needed for the future?

[Philippe Gerum]

Jan Kiszka wrote:
> Hi,
> 
> I noticed that xnhead_extend() is not used at the moment [1], thus the
> whole extent management is redundent for now. Are there plans to use it
> in the future? Should we keep this feature?
> 
> I'm asking as I still have the idea in my head of breaking up the heap
> service and introducing a generic allocator interface to select
> different heap allocators at compile time. So, should extensions be an
> optional feature of an allocator?

Keep in mind that the native API is a plain client of the abstract RTOS 
implemented by the nucleus, nothing more. What the native API does not 
use in this area would probably be useful to other clients though. For 
instance, the VRTX skin locally reimplements its own heap extension 
system that could be replaced by the nucleus one -- and should.

> 
> Jan
> 
> 
> [1]http://www.rts.uni-hannover.de/xenomai/lxr/ident?v=SVN-trunk;i=xnheap_extend
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.

Re: [Xenomai-core] Extensible heaps - needed for the future?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Hi,
>>
>> I noticed that xnhead_extend() is not used at the moment [1], thus the
>> whole extent management is redundent for now. Are there plans to use it
>> in the future? Should we keep this feature?
>>
>> I'm asking as I still have the idea in my head of breaking up the heap
>> service and introducing a generic allocator interface to select
>> different heap allocators at compile time. So, should extensions be an
>> optional feature of an allocator?
> 
> 
> Keep in mind that the native API is a plain client of the abstract RTOS
> implemented by the nucleus, nothing more. What the native API does not
> use in this area would probably be useful to other clients though. For
> instance, the VRTX skin locally reimplements its own heap extension
> system that could be replaced by the nucleus one -- and should.
> 

I did not get your point yet. To ask more directly: what functionality
should a generic real-time allocator for arbitrary size objects should
provide then?

We currently have this situation regarding the heap core:

    xnheap_init(heap, heap_memory, heap_size, page_size)
    xnheap_destroy(heap, flush_handler, handler_cookie)

    xnheap_extend(heap, extent_memory, extent_size)

    block = xnheap_alloc(heap, size)
    xnheap_test_and_free(heap, block, release_check_function)

I did not list the other functions, which are more or less wrappers
around this core (i.e. they do not need to know how the heap memory is
managed internally).

For now I have two open topics on my list:

 o page_size is BSD-allocator specific, other algorithms may need other
   arguments. We will likely rather need good defaults (isn't the
   system's page size passed here anyway?) and maybe some other
   interface to tune them.

 o As far as I understood, xnhead_extend() adds another chunk of memory
   to an existing heap. That chunk is additionally considered when
   allocating some block from that heap. Side effect: the more chunks
   you add, the longer a search may become. As I did not find any user
   of this feature and as this inherent O(n) regarding the allocation
   requires careful usage anyway, I was wondering if it is actually
   useful. If a real-time heap is too small, I would rather reserve more
   initial size (just like XENO_OPT_SYS_HEAPSZ works).

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]