From: Evgeny Voevodin <e.voevodin@samsung.com>
To: qemu-devel@nongnu.org
Cc: zhur@ispras.ru, Dmitry Solodkiy <d.solodkiy@samsung.com>
Subject: Re: [Qemu-devel] [PATCH 0/1] Fix large memory chunks allocation with tcg_malloc
Date: Mon, 05 Mar 2012 11:28:05 +0400 [thread overview]
Message-ID: <4F546B05.9050200@samsung.com> (raw)
In-Reply-To: <1330680137-6601-1-git-send-email-batuzovk@ispras.ru>
On 02.03.2012 13:22, Kirill Batuzov wrote:
> Currently large memory chunk allocation with tcg_malloc is broken. An attempt
> to allocate such chunk when pool_current field of TCGContext is not NULL will
> result in circular links in list of memory pools:
>
> p = new pool;
> s->pool_current->next = p;
> p->next = s->pool_current;
> (in tcg_malloc_internal)
>
> Later p became a current pool, and current pool became next pool. Next
> tcg_malloc will switch current pool to next pool ('previous' current pool)
> and will start allocating memory from it's beginning. But some memory in
> the beginning of this pool was already allocated and will be used twice
> for different arrays.
>
> At the end of this cover letter there is a patch that demonstrates the
> problem. It breaks current trunk on the first translation block containing
> labels.
>
> Large memory pools can not be reused by memory allocator for big allocations
> and an attempt to reuse them for small allocations may result in an infinite
> increase of memory consumption during run time. Memory consumption would
> increase every time a new large chunk of memory is allocated. If code
> allocates such chunk on every translation block (like patch at the end of this
> letter do) then memory consumption would increase with every new block
> translated.
>
> My fix for the problems mentioned above is in the second e-mail. I moved large
> memory pools to a separate list and free them on pool_reset.
>
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?
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;
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;
--
Kind regards,
Evgeny Voevodin,
Leading Software Engineer,
ASWG, Moscow R&D center, Samsung Electronics
e-mail: e.voevodin@samsung.com
next prev parent reply other threads:[~2012-03-05 7:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 9:22 [Qemu-devel] [PATCH 0/1] Fix large memory chunks allocation with tcg_malloc Kirill Batuzov
2012-03-02 9:22 ` [Qemu-devel] [PATCH 1/1] " Kirill Batuzov
2012-03-17 16:19 ` Blue Swirl
2012-03-05 7:28 ` Evgeny Voevodin [this message]
2012-03-06 12:43 ` [Qemu-devel] [PATCH 0/1] " Kirill Batuzov
2012-03-15 10:12 ` Kirill Batuzov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F546B05.9050200@samsung.com \
--to=e.voevodin@samsung.com \
--cc=d.solodkiy@samsung.com \
--cc=qemu-devel@nongnu.org \
--cc=zhur@ispras.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).