On 25 February 2013 12:50, Peter Lieven wrote:
> sth like this?
>
> diff --git a/page_cache.c b/page_cache.c
> index 376f1db..04205ee 100644
> --- a/page_cache.c
> +++ b/page_cache.c
> @@ -196,21 +196,19 @@ int64_t cache_resize(PageCache *cache, int64_t
> new_num_pages)
> /* check fo
Am 25.02.2013 um 13:36 schrieb Peter Maydell :
> On 25 February 2013 12:17, Peter Lieven wrote:
>> Am 25.02.2013 um 13:13 schrieb Peter Maydell :
>>> Doesn't this introduce a leak on cache resize in the case where
>>> the element being moved from the old cache to the new does not
>>> collide wit
On 02/25/2013 02:37 PM, Peter Lieven wrote:
>
> Am 25.02.2013 um 13:33 schrieb Orit Wasserman :
>
>> On 02/25/2013 02:17 PM, Peter Lieven wrote:
>>>
>>> Am 25.02.2013 um 13:15 schrieb Orit Wasserman :
>>>
Hi Peter,
Now I get the previous patch, it should have been a patch series :).
>>>
On 02/25/2013 02:33 PM, Orit Wasserman wrote:
> On 02/25/2013 02:17 PM, Peter Lieven wrote:
>>
>> Am 25.02.2013 um 13:15 schrieb Orit Wasserman :
>>
>>> Hi Peter,
>>> Now I get the previous patch, it should have been a patch series :).
>>> The reason we allocate from outside of the page cache is be
Am 25.02.2013 um 13:33 schrieb Orit Wasserman :
> On 02/25/2013 02:17 PM, Peter Lieven wrote:
>>
>> Am 25.02.2013 um 13:15 schrieb Orit Wasserman :
>>
>>> Hi Peter,
>>> Now I get the previous patch, it should have been a patch series :).
>>> The reason we allocate from outside of the page cache
On 25 February 2013 12:17, Peter Lieven wrote:
> Am 25.02.2013 um 13:13 schrieb Peter Maydell :
>> Doesn't this introduce a leak on cache resize in the case where
>> the element being moved from the old cache to the new does not
>> collide with any element we've already moved? [ie the code
>> path
On 02/25/2013 02:17 PM, Peter Lieven wrote:
>
> Am 25.02.2013 um 13:15 schrieb Orit Wasserman :
>
>> Hi Peter,
>> Now I get the previous patch, it should have been a patch series :).
>> The reason we allocate from outside of the page cache is because of
>> cache_resize
>> that also uses cache_in
Am 25.02.2013 um 13:13 schrieb Peter Maydell :
> On 25 February 2013 11:52, Peter Lieven wrote:
>> The page cache frees all data on finish, on resize and
>> if there is collision on insert. So it should be the caches
>> responsibility to dup the data that is stored in the cache.
>
>> diff --git
Am 25.02.2013 um 13:15 schrieb Orit Wasserman :
> Hi Peter,
> Now I get the previous patch, it should have been a patch series :).
> The reason we allocate from outside of the page cache is because of
> cache_resize
> that also uses cache_insert but doesn't duplicate the buffer.
> There is no me
Hi Peter,
Now I get the previous patch, it should have been a patch series :).
The reason we allocate from outside of the page cache is because of cache_resize
that also uses cache_insert but doesn't duplicate the buffer.
There is no memory leak because if the page is cached we don't call cache_ins
On 25 February 2013 11:52, Peter Lieven wrote:
> The page cache frees all data on finish, on resize and
> if there is collision on insert. So it should be the caches
> responsibility to dup the data that is stored in the cache.
> diff --git a/page_cache.c b/page_cache.c
> index a6c3a15..e670d91 1
The page cache frees all data on finish, on resize and
if there is collision on insert. So it should be the caches
responsibility to dup the data that is stored in the cache.
Signed-off-by: Peter Lieven
---
arch_init.c|3 +--
include/migration/page_cache.h |3 ++-
pa
12 matches
Mail list logo
