1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
permissions: 0.991
debug: 0.989
network: 0.987
peripherals: 0.986
device: 0.986
register: 0.984
performance: 0.983
arm: 0.983
assembly: 0.983
architecture: 0.983
boot: 0.982
socket: 0.981
graphic: 0.981
user-level: 0.981
risc-v: 0.981
TCG: 0.980
PID: 0.979
semantic: 0.979
kernel: 0.979
i386: 0.978
VMM: 0.978
vnc: 0.977
mistranslation: 0.976
ppc: 0.968
KVM: 0.967
virtual: 0.966
files: 0.964
hypervisor: 0.961
x86: 0.877
TCG memory leak with FreeDOS 'edit'
qemu trunk as of today leaks memory FAST when freedos' edit is running.
To reproduce, download:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/cdrom.iso
Then run:
$ qemu-system-i386 -cdrom cdrom.iso
select your language then select "return to DOS", then type
> edit
it will consume memory at ~10MB/s
This does NOT happen when adding -enable-kvm
Note, this also occurs with freeDOS 1.2, at least.
Note 2, 4.2 stable does not exhibit the bug.
Confirmed, this is still reproducible with the current v5.2-rc4...
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/283
Just to repeat the work around discussed on the GitLab page: -accel tcg,tb-size=32 will prevent the rapid increase of memory due to self modifying code.
There are two justifications for making this change. The first is that
i386 emulation is typically for smaller machines where having a 1gb of
generated code is overkill for basic emulation. The second is the
propensity of self-modifying code (c.f. Doom/edit) utilised on i386
systems can trigger a rapid growth in invalidated and re-translated
buffers. This is seen in bug #283. Execution is still inefficient but
at least the host memory isn't so aggressively used up.
That said it's still really just a sticking plaster for user
convenience.
Signed-off-by: Alex Bennée <email address hidden>
Cc: Thomas Huth <email address hidden>
Cc: <email address hidden>
---
accel/tcg/translate-all.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 640ff6e3e7..f442165674 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -951,9 +951,13 @@ static void page_lock_pair(PageDesc **ret_p1, tb_page_addr_t phys1,
* Users running large scale system emulation may want to tweak their
* runtime setup via the tb-size control on the command line.
*/
+#ifdef TARGET_I386
+#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB)
+#else
#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB)
#endif
#endif
+#endif
#define DEFAULT_CODE_GEN_BUFFER_SIZE \
(DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \
--
2.20.1
Alex Bennée <email address hidden> writes:
> There are two justifications for making this change. The first is that
> i386 emulation is typically for smaller machines where having a 1gb of
> generated code is overkill for basic emulation. The second is the
> propensity of self-modifying code (c.f. Doom/edit) utilised on i386
> systems can trigger a rapid growth in invalidated and re-translated
> buffers. This is seen in bug #283. Execution is still inefficient but
> at least the host memory isn't so aggressively used up.
>
> That said it's still really just a sticking plaster for user
> convenience.
ping?
--
Alex Bennée
Richard Henderson <email address hidden> writes:
> On 5/25/21 9:45 AM, Alex Bennée wrote:
>> There are two justifications for making this change. The first is that
>> i386 emulation is typically for smaller machines where having a 1gb of
>> generated code is overkill for basic emulation. The second is the
>> propensity of self-modifying code (c.f. Doom/edit) utilised on i386
>> systems can trigger a rapid growth in invalidated and re-translated
>> buffers. This is seen in bug #283. Execution is still inefficient but
>> at least the host memory isn't so aggressively used up.
>> That said it's still really just a sticking plaster for user
>> convenience.
>> Signed-off-by: Alex Bennée <email address hidden>
>> Cc: Thomas Huth <email address hidden>
>> Cc: <email address hidden>
>> ---
>> accel/tcg/translate-all.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
>> index 640ff6e3e7..f442165674 100644
>> --- a/accel/tcg/translate-all.c
>> +++ b/accel/tcg/translate-all.c
>> @@ -951,9 +951,13 @@ static void page_lock_pair(PageDesc **ret_p1, tb_page_addr_t phys1,
>> * Users running large scale system emulation may want to tweak their
>> * runtime setup via the tb-size control on the command line.
>> */
>> +#ifdef TARGET_I386
>> +#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB)
>> +#else
>> #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB)
>> #endif
>> #endif
>> +#endif
>> #define DEFAULT_CODE_GEN_BUFFER_SIZE \
>> (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \
>>
>
> I'm not thrilled, as it is ultra-hacky.
I don't disagree.
> (1) I've got a re-org of this code out for review:
> https://<email address hidden>/
OK I'll have a look at that.
> (2) I'm keen to reorg TCG such that it gets compiled once. There's
> currently nothing standing in the way of that except work. But this
> would introduce a use of a target-specific define for the first time
> into tcg/. I guess I could leave the default sizing back in
> accel/tcg/ and pass in the default.
>
> Other options?
Some random thoughts in no particular order:
- a separately flushable translation region for code we detect as SMC heavy
- a front-end interpreter for SMC code
- smarter code generation that dynamically loads values from codemem
(usually the SMC code is just tweaking an #imm value)
None of these seem particularly amenable to a clean non-complex
implementation though. A front-end interpreter would be useful for other
things though - it could even be incomplete and handle only common code
patterns falling back to full generation for anything it can't handle.
>
>
> r~
--
Alex Bennée
|