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

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.
>
>
> Thank you,
>
> Alex.

+1.

Amos
Received on Fri Jul 13 2012 - 03:06:01 MDT