qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/1] Fix large memory chunks allocation with tcg


From: Kirill Batuzov
Subject: Re: [Qemu-devel] [PATCH 0/1] Fix large memory chunks allocation with tcg_malloc
Date: Tue, 6 Mar 2012 16:43:35 +0400 (MSK)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)


On Mon, 5 Mar 2012, Evgeny Voevodin wrote:

> 
> As I understand, your approach removes linking back to the previous allocated
> chunk to avoid usage of already allocated and used memory again. Also you
> added g_free() to tcg_pool_reset(). Wouldn't it slow down emulation?

No, it would not.  I added g_free() for large memory chunks only.
Emulation runs which use only small allocations are unaffected.
If an emulation run uses a large memory allocation - well, it was broken
before.  So there is nothing to compare speed to in this case.

> Maybe such linkage to previous chunk was made with assumption that big
> allocations will not happen twice one after another? For example, while
> loading kernel on realview and exynos, the code never reaches this string in
> tcg_malloc_internal():
> 
> p->next = s->pool_current;
> 

The corresponding code had not changed since 2008.  And, probably, never
worked.  It would be hard to know now what the author wanted from this code
back then.

> If this assumption is correct, maybe it's better to just insert a verification
> that allocated chunk has enough space to hold requested block?
> 
> +   if (s->pool_cur - p->data + size > p->size) {
> +       goto new_pool;
> +   }
> 
>     s->pool_current = p;
>     s->pool_cur = p->data + size;
>     s->pool_end = p->data + p->size;
>     return p->data;
> 

First, this verification does not solve problem of circular links in
the list.
Second, it does not solve problem of unbound increase of memory
consumption.

I probably should clarify that I found this issue when I was writing
an unrelated modification to the register allocator which required large memory
allocations.  Current code in TCG probably never does such allocations
and does not trigger memory corruption.

-- 
Kirill Batuzov



reply via email to

[Prev in Thread] Current Thread [Next in Thread]