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
|
performance: 0.601
device: 0.459
graphic: 0.414
user-level: 0.389
architecture: 0.364
network: 0.208
arm: 0.195
kernel: 0.180
semantic: 0.178
files: 0.163
register: 0.140
socket: 0.107
x86: 0.090
debug: 0.080
PID: 0.075
ppc: 0.071
permissions: 0.067
peripherals: 0.064
mistranslation: 0.052
boot: 0.048
i386: 0.045
virtual: 0.033
VMM: 0.028
vnc: 0.028
risc-v: 0.027
assembly: 0.025
hypervisor: 0.024
TCG: 0.021
KVM: 0.011
linux-user/mmap exhaustion
Currently when executing a linux-user target, mmap.c is in use- the model it uses internally for figuring out what the mmap address actually should be basically is an accumulator, every mmap invocation (regardless of munmap's that cleared the previous usage) is center on the next page.
The end result of this is that it'll burn it's way through the space soon enough, especially if it's a 64bit host w/ a 32bit target- the host starts giving back 64bit addresses and the emulated mmap falls over after failed attempts at a low MAP_FIXED range.
Where this becomes problematic is that glibc's FILE internals mmap a *lot*- once per handle. Any long running process can hit this wall- rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so it hits the wall surprisingly fast- at least on an opensuse 11.2 system w/ mmap_min_addr of 65536 (their default), building qt reliably hits that exhaustion during packaging.
Attached is basically, a hack- but one that works surprisingly well and at least for meego building via qemu-arm, eliminates the failure scenario I've described above. It doesn't remove the exhaustion as much as push it a fair bit back, although there are still a couple of ways to trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the only remaining example I'm aware of).
This patch simply checks to see if upon an actual, host level munmap, if the ending point of the munmap is where we'd allocate from next- if so, it shifts the starting point back to the (now) unmap'd start, reusing the space. Rebuilding meego a couple of times over, thus far I've not managed to flush out any failures that point at this specific patch, so... it looks like it's doing the trick- that said the lack of a g2h/h2g in the calculation still seems questionable to me.
Triaging old bug tickets ... do you still have this issue with the latest version of QEMU? If so, could you please discuss the patch on the qemu-devel mailing list? (since we do not take patches from the bugtracker)
[Expired for QEMU because there has been no activity for 60 days.]
|