Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Hi,
>  > 
>  > this patch moves the heap for scalable timer queues into the xnpod_t
>  > structure instead of allocating it dynamically. This simplifies the pod
>  > initialisation and cleanup, which was not fully robust in this regard
>  > anyway. If a pod is now considered too large (but we are discussion
>  > kbytes here), allocating its buffer via xnarch_sysalloc would be an option.
>  > 
>  > In case this patch is acceptable, I would suggest merging it before 2.2
>  > due to the contained (minor) fix.
> 
> Since this memory is specific to the data structure, its allocation
> seems better by the data structure functions. It also make the binary
> heap structure reusable for other purposes.

That's what I added the DECLARE_BHEAP_CONTAINER macro for. Sorry, did
not mention this.

The idea is to leave the allocation policy up to the user instead of
enforcing it in the bheap layer. The current approach also implicitly
excludes its usage from RT contexts, BTW.

> 
> Could you explain why the current scheme is not robust ?
> 

Given a SMP system where the allocation fails right in the middle of the
per-CPU loop [1], cleanup will not be performed for already allocated heaps.

Jan


[1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pod.c?v=SVN-trunk#L432

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to