[Top][All Lists]

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

[Qemu-discuss] ASan'ed binaries start up very slow under qemu-aarch64.

From: Maxim Ostapenko
Subject: [Qemu-discuss] ASan'ed binaries start up very slow under qemu-aarch64.
Date: Mon, 18 Jul 2016 17:45:15 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1


When testing AddressSanitizer tool for AArch64 under qemu-aarch64 (user mode), I found out that even trivial helloworld apps start extremely slow (~2 seconds). I've investigated this a bit and noticed that QEMU actually freezes in large mmaps and subsequent reads of /proc/self/maps. Here a scenario I observed:

1) AddressSanitizer mmaps quite large regions of memory for redzones and shadow gap. In particular, for 39-bit AS it mmapes:

|| `[0x1400000000, 0x1fffffffff]` || HighShadow || - 48 Gb
|| `[0x1200000000, 0x13ffffffff]` || ShadowGap  || - 8 Gb
|| `[0x1000000000, 0x11ffffffff]` || LowShadow  || - 4 Gb

2) In QEMU, page_set_flags is called for these ranges. It cuts given range to individual pages and sets flags for them. Given the page size is 4 Kb, for 8 Gb range we have 2097152 iterations and for 48 Gb 12582912 iterations in inner loop. This is obviously a performance bottleneck.

3) Same issue may happen when ASan tries to read /proc/self/map later in page_check_range function, after it already mmaped HighShadow, ShadowGap and LowShadow regions.

Could someone help me, how can I mitigate this performance issue? Do we really need to set flags to each page on entire (quite big) memory region?


reply via email to

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