Re: [PATCH] trimMemory for unswappable objects

On 01/11/2012 01:53 PM, Amos Jeffries wrote:
> On 11/01/2012 12:39 a.m., Tsantilas Christos wrote:
>> Inside StoreEntry::swapOut() the StoreEntry::trimMemory() method called
>> to release unused MemObjects memory. The trimMemory method must called
>> for all store entries, but current code blocks that call for
>> not-swappable objects, at least.
>>
>> This patch trying to fix this bug implementing the following simple
>> logic:
>> {
>> bool weAreOrMayBeSwappingOut =
>> swappingOut() || mayStartSwapout();
>>
>> trimMemory(weAreOrMayBeSwappingOut);
>>
>> if (!weAreOrMayBeSwappingOut)
>> return; // nothing else to do
>> }
>>
>> This is a Measurement Factory project
>
> Regarding your comment:
> "
> + * NOTE: the store_maxobjsize here is the max of optional
> + * max-size values from 'cache_dir' lines. It is not the
> + * same as 'maximum_object_size'. By default, store_maxobjsize
> + * will be set to -1. However, I am worried that this
> + * deferance may consume a lot of memory in some cases.
> + * Should we add an option to limit this memory consumption?
> "
>
> There is always the option of setting some upper limit on the amount
> back-buffered. If you do there is the min-size for each cache_dir to be
> surpassed before data starts getting swapped out. Default 0 bytes, but
> if set higher that will be a lower bound on how much to buffer. Between
> the two limts anything may go at present.
>
>
> NP: your patch for bug 3417 slipped in.
>
> On the whole it looks good from a quick scan.
>
> +1, but note I'm not up to scratch on the surrounding code to assess it
> fully.
>

I tried to make enough tests. It run in my testing squid for some days
without any problem.

If there is not any objection I will commit this patch to trunk.

> Amos
>
Received on Thu Jan 12 2012 - 15:29:23 MST