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 _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
