On Wed, 2012-02-15 at 07:52 -0500, Stephen Gallagher wrote:
On Wed, 2012-02-15 at 09:28 +0100, Pavel Březina wrote:
> - if we change the parent of a child of talloc pool to a parent that is
> outside of this pool, the whole pool memory will not be freed until
> the child is freed.
This part makes me REALLY nervous. We do a LOT of talloc stealing all
over the place (in the case of the provider lookups, we often steal
request memory onto long-running responder contexts). Using pools could
very easily result in our ending up with a significantly larger memory
footprint. I think we want to be VERY careful about how we use this, if
at all.
This is the reason I did not introduce the use of pools nor the
talloc_tos() optimization that samba also added.
The reason why pools and tos are easily usable in the samba file server
code is that they are very request based, so there is a very high
confidence that all the memory will be freed once the request is
finished and returned to the main loop. It is not so clearcut with sssd.
That said I think we could introduce the use of pools carefully after
profiling critical sections of the code if we see that malloc takes a
big chunk of the performance.
Jan's comments about using a pool to handle realloc() loops are
interesting, but it would still require us to have a good sense of how
large a pool we needed in the average case (otherwise it will just end
up resorting to using standard contexts anyway, negating our
advantages).
agree, we should use pools carefully in critical sections, tailored to
the memory allocation needs of that area of the code.
Simo.
--
Simo Sorce * Red Hat, Inc * New York