> 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.
That's true. We would need to copy the memory to a new location and then free the old one. The question is if it would bring any improvement. > 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). I don't think so. I mean having the information about average case will certainly be helpful but if you set lower number, it won't hurt. Even if you set the size to be twice as large as one element in the array takes, you would still save 50% of reallocs and that's worth it IMO. Jan
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
