Re: [PATCH v3] Do not release entries that may be kept in local memory cache.

On 07/12/2012 09:05 PM, Amos Jeffries wrote:
> On 13/07/2012 10:15 a.m., Alex Rousskov wrote:
>> On 07/06/2012 10:08 PM, Alex Rousskov wrote:
>>> On 07/06/2012 07:11 PM, Amos Jeffries wrote:
>>>> On 7/07/2012 2:36 a.m., Alex Rousskov wrote:
>>>>> If I get your primary idea correctly, then instead of
>>>>> StoreEntry::swapOut() calling e.trimMemory() it will call new
>>>>> StoreController::trimMemory(e) and the controller would decide whether
>>>>> to proceed with trimming and, if yes, will call e.trimMemory().
>>>>> StoreEntry::trimMemory() will not have any new conditions added then.
>>>>>
>>>>> If that is what you are suggesting, it sounds good to me, and I can do
>>>>> that during commit of v3 patch (it would not change the
>>>>> functionality or
>>>>> the order of the checks; just move a couple of checks to a different
>>>>> class/method).
>>>> Yes that was what I meant. And yes it is a design change, the renamed
>>>> functions just make it abundantly clearer that portage is either not
>>>> possible or needs more than usual careful checking.
>>> Since we are not changing the lower-level MemObject methods that do the
>>> actual trimming, I will not rename them. I will add a "maybe" prefix to
>>> StoreEntry::trimMemory(). I hope this is a reasonable compromise.
>>
>> Attached is the third take on this fix. Seems to work OK in my tests. I
>> think it meets the requirements discussed so far and can be committed
>> now, but please let me know if you would like to see more changes.
>>
>> Patch preamble has the technical details.

> +1.

Committed to trunk as r12205. Please apply to v3.2 as well.

Thank you,

Alex.
Received on Fri Jul 13 2012 - 14:40:22 MDT