Jan Kiszka wrote:
> 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.
You are right.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
