|
From: <sv...@va...> - 2014-09-22 19:46:56
|
Author: philippe
Date: Mon Sep 22 19:46:48 2014
New Revision: 14562
Log:
Fix some comments that were still describing 32Gb as the limit for 'fast' memcheck
Modified:
trunk/memcheck/mc_main.c
Modified: trunk/memcheck/mc_main.c
==============================================================================
--- trunk/memcheck/mc_main.c (original)
+++ trunk/memcheck/mc_main.c Mon Sep 22 19:46:48 2014
@@ -138,11 +138,11 @@
On 64-bit machines it's more complicated. If we followed the same basic
scheme we'd have a four-level table which would require too many memory
- accesses. So instead the top-level map table has 2^19 entries (indexed
- using bits 16..34 of the address); this covers the bottom 32GB. Any
- accesses above 32GB are handled with a slow, sparse auxiliary table.
+ accesses. So instead the top-level map table has 2^20 entries (indexed
+ using bits 16..35 of the address); this covers the bottom 64GB. Any
+ accesses above 64GB are handled with a slow, sparse auxiliary table.
Valgrind's address space manager tries very hard to keep things below
- this 32GB barrier so that performance doesn't suffer too much.
+ this 64GB barrier so that performance doesn't suffer too much.
Note that this file has a lot of different functions for reading and
writing shadow memory. Only a couple are strictly necessary (eg.
|