Title: #999: Mem-cache fixes/improvements
> From developers perspective, I would rather go in totally
different way as opposite to "average payload" (btw, justification of those
factors in the comments in the source code is very loose). I would prefer to get rid of
fixed slot size completly (I must admit I didn't investigate performance impact yet
but my gut feeling is it should be ok). But this would be quite large refactoring and
intention of this PR - to resolve specific bug and to provide at least basic means to
ajust cache for NSS load...
Originally the slot size was 32bytes and the fixed slot size together with all the memory
alignment was use to make sure the a slot or 2 will fix into a CPU cache line. This was of
course broken by extending the slot size to 40.
As it was discussed on IRC, this is more about sizes and alignment of
"sss_mc_rec" and "sss_mc_*_data" headers. I still think MC_SLOT_SIZE
per se is only implicitly relevant.
But I think the original idea was good and in the long term it would
be good to come back to 32bytes (or maybe 64bytes). I'm not sure if a flexible slot
size would have much benefits.
Benefits would be:
(1) code simplification;
(2) less memory waste.
But I agree performance impact should be measured.
But this perhaps means it is better to configure size of cache in megabytes, not in slots
(to avoid change of user visible semantic later)...
If you prefer the number of slots as a config option I would suggest
to make the factor between the data and the hash table size (aka "payload")
either constantly 4 or even 1. The latter will of course increase the hash table size but
with the positive side effect that there might be less collisions.
I changed the patch to use constant factor and opted to 2 (because every entry takes 2
slots at the very least).
Please, take a look at this version.
See the full comment at https://github.com/SSSD/sssd/pull/999#issuecomment-601770502