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

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Thu, 12 Jul 2012 16:15:16 -0600

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.

Received on Thu Jul 12 2012 - 22:15:29 MDT

This archive was generated by hypermail 2.2.0 : Fri Jul 13 2012 - 12:00:03 MDT