[Top][All Lists]
[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