[squid-dev] [PATCH] mempools-nozero: turn StoreEntry into MEMPROXY_CLASS
Alex Rousskov
rousskov at measurement-factory.com
Mon Aug 31 20:29:00 UTC 2015
On 08/29/2015 08:03 PM, Kinkie wrote:
> On Aug 28, 2015 7:24 PM, Alex Rousskov wrote:
> Perhaps there a way to avoid this particular part of the change
> and keep the StoreEntry chunk sizes the same as they are today?
> Unfortunately not if we want to proceed with MEMPROXY_CLASS conversion,
> which doesn't expose that method, and MEMPROXY_CLASS is with this branch
> the easiest (I would dare to say standard) way to go to non-zeroing pools.
If you can avoid the problem by exposing and using that method, I think
that would be a good solution.
> I've tried to figure out the code some more; comments highlight that
> it's an optimization feature, which is only effective with the chunked
> allocator - it is otherwise a nop.
> I believe this hint its is meant to try and alter the behavior of the
> chunked allocator - in a roundabout way - hinting that the objects in
> the pool are important and thus to try and make that particular object
> pool less sensitive to memory pressure, by ensuring that if even a
> single StoreEntry can be allocated, there will be at least
> (chunk_size/obj_size -1) available memory areas until all of them have
> been released.
> ... I suspect that whatever is the optimization value of
> chunk size setting, it is dwarfed by other effects and is speculative;
> at the same time we have a sure gain by not initializing objects twice
> (one when zeroing the pool, and then in the constructor).
> For this reason, I would like to go ahead with the merge, I agree it's a
> good idea to isolate this patch into a separate commit, and to mark it
> as potentially performance-impacting in the commit message.
> Please let me know if you agree.
I may not agree with some of the above statements, but I do not object
to this change going in (in a dedicated commit) if you think that is the
best way forward (and others do not object).
Thank you,
Alex.
More information about the squid-dev
mailing list