You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(17) |
2
(14) |
3
(15) |
4
(30) |
5
(18) |
6
(12) |
7
(10) |
|
8
(11) |
9
(11) |
10
(14) |
11
(12) |
12
(12) |
13
(8) |
14
(5) |
|
15
(11) |
16
(19) |
17
(15) |
18
(15) |
19
(16) |
20
(9) |
21
(9) |
|
22
(12) |
23
(11) |
24
(10) |
25
(5) |
26
(11) |
27
(12) |
28
(20) |
|
29
(11) |
30
(21) |
|
|
|
|
|
|
From: Pandurangan R S <pan...@gm...> - 2008-06-06 19:04:21
|
> As for documentation, the PLDI '07 paper is rather nice to get you started > (http://valgrind.org/docs/pubs.html ) Thanks, this is a very nice reference. It answers lot of questions that I had and provides much more information! On Thu, Jun 5, 2008 at 11:42 PM, Filipe Cabecinhas <fi...@gm...> wrote: > Hi, > > On 5 Jun, 2008, at 17:07, Pandurangan R S wrote: >> >> I assume that valgrind checks each memory access, against this tables. But >> how >> does valgrind intercept every memory access so that it can lookup this >> table? >> This might be very basic question, but I could not find how valgrind >> checks >> every access. Any pointers or document references related to this will be >> great. > > > Valgrind never runs the original code. It uses VEX to read your program, > lets memcheck (or another tool) instrument it and then generates binary code > to run. > > So the code you saw in memcheck is code to instrument the IR to check the > original program's memory accesses. > > As for documentation, the PLDI '07 paper is rather nice to get you started > (http://valgrind.org/docs/pubs.html ) > > - Filipe Cabecinhas > > > > |
|
From: Josef W. <Jos...@gm...> - 2008-06-06 17:37:59
|
On Friday 06 June 2008, Nicholas Nethercote wrote:
> On Thu, 5 Jun 2008, Josef Weidendorfer wrote:
> > The LRU list of L1 now is (a1, a2), and the one of L2 is still (a2, a1).
>
> In short: when an L1 hit occurs, the L1 MRU list is updated, but the L2 MRU
> list is not, right?
Yes.
> Hmm, I think your analysis is correct. I hope anyone
> that is using Cachegrind for serious analysis is plugging their own cache
> simulator into it.
>
> Making the simulation correct so that it is properly inclusive seems like a
> good thing to do.
Yes, but of course this depends both on performance and results effect.
> Would you be able to work up a patch that does this,
First try:
Modify the simulation macro to add a HIT_TREATMENT, and for I1/D1, on a hit
do a L2 reference, the same way as on a miss. This adjusts the L2 MRU lists.
With an inclusive cache, a L2 reference after a L1 hit always should give a
hit in L2, too...
So with the macro definition (and according additions in the macro)
#define CACHESIM(L, MISS_TREATMENT, HIT_TREATMENT) ...
we can check for the inclusion property with
CACHESIM(D1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2); },
{ cachesim_L2_doref(a, size, 0, 0); } );
Note that for a L1 hit, we call the L2 reference with m1/m2 as zero pointers.
Thus, if there is a L2 miss instead, there will be a segfault.
And really, this crashes already with small programs on my Pentium-M laptop :-(
So even with this addition, the cache simulation is not really fully inclusive...
I can only assume what is going on:
On my laptop, the Pentium-M has an 8-way associative for L1D, L1I and L2 (which also
is used as parameter by Cachegrind). For addresses mapping into the same set,
L1 and I1 *each* can hold 8 cache lines, while the unified L2 can hold 8 lines only.
So there is the possibility that lines are evicted from L2 which still are in
L1D or L1I, even with adjusted MRU list.
To really get inclusive behavior, everytime a cacheline is evicted (from L1D, L1I or
L2), we would need to invalidate it in the other caches. This probably would get
really messy.
In other words, I do not think that the above change is worth it.
Here are some numbers with running bzip2 on a 1.2MB binary file
("time valgrind --tool=cachegrind bzip2 -c libc.so.6 >/dev/null"):
ORIGINAL Cachegrind:
==11957== L2 refs: 16,674,882 ( 9,690,259 rd + 6,984,623 wr)
==11957== L2 misses: 1,504,180 ( 888,988 rd + 615,192 wr)
==11957== L2 miss rate: 0.0% ( 0.0% + 0.4% )
real 0m43.337s
user 0m42.019s
sys 0m0.088s
MODIFIED Cachegrind (L2 ref also on L1 hit, but these refs are not counted in the
results):
==12708== L2 refs: 16,674,882 ( 9,690,259 rd + 6,984,623 wr)
==12708== L2 misses: 1,506,936 ( 890,131 rd + 616,805 wr)
==12708== L2 miss rate: 0.0% ( 0.0% + 0.4% )
real 0m53.941s
user 0m53.603s
sys 0m0.128s
One can see that there really are changes in L2 misses: 0,18% more.
But the "better" simulation takes 27% more time :(
Of course, "bzip2" is a bad example for this "extension": before, most accesses
where L1 hits. With the modification, there always is a lookup in L2, too.
IMHO the easiest way to handle this is to note in the manual that the
"inclusive" cache property is not really met by Cachegrinds simulation,
but results should be quite close (enough for the purpose of analyzing cach
performance).
Josef
|
|
From: <sv...@va...> - 2008-06-06 14:31:31
|
Author: bart
Date: 2008-06-06 15:31:36 +0100 (Fri, 06 Jun 2008)
New Revision: 8196
Log:
Speed up analysis of programs that access the thread stack intensively.
Modified:
trunk/exp-drd/drd_main.c
trunk/exp-drd/drd_thread.h
trunk/exp-drd/scripts/run-splash2
Modified: trunk/exp-drd/drd_main.c
===================================================================
--- trunk/exp-drd/drd_main.c 2008-06-06 10:18:24 UTC (rev 8195)
+++ trunk/exp-drd/drd_main.c 2008-06-06 14:31:36 UTC (rev 8196)
@@ -70,11 +70,11 @@
// Local variables.
-static Bool s_drd_check_stack_var = False;
-static Bool s_drd_print_stats = False;
-static Bool s_drd_trace_fork_join = False;
-static Bool s_drd_var_info = False;
-static Bool s_show_stack_usage = False;
+static Bool s_drd_check_stack_accesses = False;
+static Bool s_drd_print_stats = False;
+static Bool s_drd_trace_fork_join = False;
+static Bool s_drd_var_info = False;
+static Bool s_show_stack_usage = False;
//
@@ -84,22 +84,22 @@
static Bool drd_process_cmd_line_option(Char* arg)
{
int exclusive_threshold_ms = -1;
- int segment_merging = -1;
+ int segment_merging = -1;
int shared_threshold_ms = -1;
- int show_confl_seg = -1;
- int trace_barrier = -1;
- int trace_clientobj = -1;
- int trace_cond = -1;
- int trace_csw = -1;
- int trace_danger_set = -1;
- int trace_mutex = -1;
- int trace_rwlock = -1;
- int trace_segment = -1;
- int trace_semaphore = -1;
- int trace_suppression = -1;
- Char* trace_address = 0;
+ int show_confl_seg = -1;
+ int trace_barrier = -1;
+ int trace_clientobj = -1;
+ int trace_cond = -1;
+ int trace_csw = -1;
+ int trace_danger_set = -1;
+ int trace_mutex = -1;
+ int trace_rwlock = -1;
+ int trace_segment = -1;
+ int trace_semaphore = -1;
+ int trace_suppression = -1;
+ Char* trace_address = 0;
- VG_BOOL_CLO (arg, "--check-stack-var", s_drd_check_stack_var)
+ VG_BOOL_CLO (arg, "--check-stack-var", s_drd_check_stack_accesses)
else VG_BOOL_CLO(arg, "--drd-stats", s_drd_print_stats)
else VG_BOOL_CLO(arg, "--segment-merging", segment_merging)
else VG_BOOL_CLO(arg, "--show-confl-seg", show_confl_seg)
@@ -278,7 +278,8 @@
{
drd_trace_mem_access(addr, size, eLoad);
}
- if (bm_access_load_triggers_conflict(addr, addr + size))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_load_triggers_conflict(addr, addr + size))
{
drd_report_race(addr, size, eLoad);
}
@@ -293,7 +294,8 @@
{
drd_trace_mem_access(addr, 1, eLoad);
}
- if (bm_access_load_1_triggers_conflict(addr))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_load_1_triggers_conflict(addr))
{
drd_report_race(addr, 1, eLoad);
}
@@ -308,7 +310,8 @@
{
drd_trace_mem_access(addr, 2, eLoad);
}
- if (bm_access_load_2_triggers_conflict(addr))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_load_2_triggers_conflict(addr))
{
drd_report_race(addr, 2, eLoad);
}
@@ -323,7 +326,8 @@
{
drd_trace_mem_access(addr, 4, eLoad);
}
- if (bm_access_load_4_triggers_conflict(addr))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_load_4_triggers_conflict(addr))
{
drd_report_race(addr, 4, eLoad);
}
@@ -338,7 +342,8 @@
{
drd_trace_mem_access(addr, 8, eLoad);
}
- if (bm_access_load_8_triggers_conflict(addr))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_load_8_triggers_conflict(addr))
{
drd_report_race(addr, 8, eLoad);
}
@@ -360,7 +365,8 @@
{
drd_trace_mem_access(addr, size, eStore);
}
- if (bm_access_store_triggers_conflict(addr, addr + size))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_store_triggers_conflict(addr, addr + size))
{
drd_report_race(addr, size, eStore);
}
@@ -375,7 +381,8 @@
{
drd_trace_mem_access(addr, 1, eStore);
}
- if (bm_access_store_1_triggers_conflict(addr))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_store_1_triggers_conflict(addr))
{
drd_report_race(addr, 1, eStore);
}
@@ -390,7 +397,8 @@
{
drd_trace_mem_access(addr, 2, eStore);
}
- if (bm_access_store_2_triggers_conflict(addr))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_store_2_triggers_conflict(addr))
{
drd_report_race(addr, 2, eStore);
}
@@ -405,7 +413,8 @@
{
drd_trace_mem_access(addr, 4, eStore);
}
- if (bm_access_store_4_triggers_conflict(addr))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_store_4_triggers_conflict(addr))
{
drd_report_race(addr, 4, eStore);
}
@@ -420,7 +429,8 @@
{
drd_trace_mem_access(addr, 8, eStore);
}
- if (bm_access_store_8_triggers_conflict(addr))
+ if ((s_drd_check_stack_accesses || ! thread_address_on_stack(addr))
+ && bm_access_store_8_triggers_conflict(addr))
{
drd_report_race(addr, 8, eStore);
}
@@ -473,7 +483,8 @@
}
}
-static void drd_start_using_mem(const Addr a1, const SizeT len)
+static __inline__
+void drd_start_using_mem(const Addr a1, const SizeT len)
{
tl_assert(a1 < a1 + len);
@@ -509,7 +520,7 @@
{
drd_trace_mem_access(a1, len, eEnd);
}
- if (! is_stack_mem || s_drd_check_stack_var)
+ if (! is_stack_mem || s_drd_check_stack_accesses)
{
thread_stop_using_mem(a1, a2);
clientobj_stop_using_mem(a1, a2);
@@ -583,7 +594,8 @@
/* Called by the core when the stack of a thread grows, to indicate that */
/* the addresses in range [ a, a + len [ may now be used by the client. */
/* Assumption: stacks grow downward. */
-static void drd_start_using_mem_stack(const Addr a, const SizeT len)
+static __inline__
+void drd_start_using_mem_stack(const Addr a, const SizeT len)
{
thread_set_stack_min(thread_get_running_tid(), a - VG_STACK_REDZONE_SZB);
drd_start_using_mem(a - VG_STACK_REDZONE_SZB,
@@ -593,7 +605,8 @@
/* Called by the core when the stack of a thread shrinks, to indicate that */
/* the addresses [ a, a + len [ are no longer accessible for the client. */
/* Assumption: stacks grow downward. */
-static void drd_stop_using_mem_stack(const Addr a, const SizeT len)
+static __inline__
+void drd_stop_using_mem_stack(const Addr a, const SizeT len)
{
thread_set_stack_min(thread_get_running_tid(),
a + len - VG_STACK_REDZONE_SZB);
@@ -649,7 +662,7 @@
"drd_post_thread_create created = %d/%d",
vg_created, drd_created);
}
- if (! s_drd_check_stack_var)
+ if (! s_drd_check_stack_accesses)
{
drd_start_suppression(thread_get_stack_max(drd_created)
- thread_get_stack_size(drd_created),
@@ -691,7 +704,7 @@
VG_(free)(msg);
}
- if (! s_drd_check_stack_var)
+ if (! s_drd_check_stack_accesses)
{
drd_finish_suppression(thread_get_stack_max(drd_joinee)
- thread_get_stack_size(drd_joinee),
Modified: trunk/exp-drd/drd_thread.h
===================================================================
--- trunk/exp-drd/drd_thread.h 2008-06-06 10:18:24 UTC (rev 8195)
+++ trunk/exp-drd/drd_thread.h 2008-06-06 14:31:36 UTC (rev 8196)
@@ -162,20 +162,20 @@
&& s_threadinfo[tid].detached_posix_thread == False));
}
-static inline
+static __inline__
DrdThreadId thread_get_running_tid(void)
{
tl_assert(s_drd_running_tid != DRD_INVALID_THREADID);
return s_drd_running_tid;
}
-static inline
+static __inline__
struct bitmap* thread_get_danger_set(void)
{
return s_danger_set;
}
-static inline
+static __inline__
Bool running_thread_is_recording(void)
{
tl_assert(0 <= (int)s_drd_running_tid && s_drd_running_tid < DRD_N_THREADS
@@ -184,7 +184,7 @@
&& s_threadinfo[s_drd_running_tid].is_recording);
}
-static inline
+static __inline__
void thread_set_stack_min(const DrdThreadId tid, const Addr stack_min)
{
#if 0
@@ -203,8 +203,18 @@
}
}
+/** Return true if and only if the specified address is on the stack of the
+ * currently scheduled thread.
+ */
+static __inline__
+Bool thread_address_on_stack(const Addr a)
+{
+ return (s_threadinfo[s_drd_running_tid].stack_min <= a
+ && a < s_threadinfo[s_drd_running_tid].stack_max);
+}
+
/** Return a pointer to the latest segment for the specified thread. */
-static inline
+static __inline__
Segment* thread_get_segment(const DrdThreadId tid)
{
tl_assert(0 <= (int)tid && tid < DRD_N_THREADS
@@ -214,7 +224,7 @@
}
/** Return a pointer to the latest segment for the running thread. */
-static inline
+static __inline__
Segment* running_thread_get_segment(void)
{
return thread_get_segment(s_drd_running_tid);
Modified: trunk/exp-drd/scripts/run-splash2
===================================================================
--- trunk/exp-drd/scripts/run-splash2 2008-06-06 10:18:24 UTC (rev 8195)
+++ trunk/exp-drd/scripts/run-splash2 2008-06-06 14:31:36 UTC (rev 8196)
@@ -97,17 +97,17 @@
# Results: (-p1) (-p2) (-p3) (-p4) ITC (-p4) ITC (-p4)
# original w/ filter
# .........................................................................
-# Cholesky 39 49 ? 81 239 82
-# FFT 15 16 N/A 43 90 41
-# LU, contiguous blocks 38 39 ? 43 428 128
-# LU, non-contiguous blocks 32 34 ? 41 428 128
-# Ocean, contiguous partitions 19 23 N/A 29 90 28
-# Ocean, non-continguous partns 18 21 N/A 31 90 28
-# Radiosity 92 92 ? 92 485 163
-# Radix 11 14 ? 16 222 56
-# Raytrace 70 70 ? 70 172 53
-# Water-n2 50 50 ? 50 189 39
-# Water-sp 49 48 ? 49 183 34
+# Cholesky 40 47 ? 82 239 82
+# FFT 16 17 N/A 47 90 41
+# LU, contiguous blocks 39 41 ? 45 428 128
+# LU, non-contiguous blocks 39 41 ? 49 428 128
+# Ocean, contiguous partitions 17 19 N/A 25 90 28
+# Ocean, non-continguous partns 18 21 N/A 30 90 28
+# Radiosity 78 78 ? 78 485 163
+# Radix 10 12 ? 15 222 56
+# Raytrace 56 56 ? 56 172 53
+# Water-n2 34 34 ? 34 189 39
+# Water-sp 33 33 ? 33 183 34
#
# Hardware: dual-core Intel Xeon 5130, 1.995 MHz, 4 MB L2 cache, 4 GB RAM.
# Software: Ubuntu 7.10 server, 64-bit (includes gcc 4.1.3).
|
|
From: <sv...@va...> - 2008-06-06 10:18:23
|
Author: bart
Date: 2008-06-06 11:18:24 +0100 (Fri, 06 Jun 2008)
New Revision: 8195
Log:
Enable more optimization opportunities.
Modified:
trunk/exp-drd/Makefile.am
trunk/exp-drd/drd_main.c
trunk/exp-drd/drd_thread.c
trunk/exp-drd/drd_thread.h
Modified: trunk/exp-drd/Makefile.am
===================================================================
--- trunk/exp-drd/Makefile.am 2008-06-06 10:17:26 UTC (rev 8194)
+++ trunk/exp-drd/Makefile.am 2008-06-06 10:18:24 UTC (rev 8195)
@@ -97,11 +97,8 @@
drd_malloc_wrappers.c \
drd_mutex.c \
drd_rwlock.c \
- drd_segment.c \
drd_semaphore.c \
- drd_suppression.c \
- drd_thread.c \
- drd_vc.c
+ drd_suppression.c
noinst_HEADERS = \
drd_barrier.h \
Modified: trunk/exp-drd/drd_main.c
===================================================================
--- trunk/exp-drd/drd_main.c 2008-06-06 10:17:26 UTC (rev 8194)
+++ trunk/exp-drd/drd_main.c 2008-06-06 10:18:24 UTC (rev 8195)
@@ -54,6 +54,15 @@
#include "pub_tool_tooliface.h"
+/* Include several source files here in order to allow the compiler to */
+/* do more inlining. */
+#include "drd_bitmap.c"
+#include "drd_segment.c"
+#include "drd_thread.c"
+#include "drd_vc.c"
+
+
+
// Function declarations.
static void drd_start_client_code(const ThreadId tid, const ULong bbs_done);
Modified: trunk/exp-drd/drd_thread.c
===================================================================
--- trunk/exp-drd/drd_thread.c 2008-06-06 10:17:26 UTC (rev 8194)
+++ trunk/exp-drd/drd_thread.c 2008-06-06 10:18:24 UTC (rev 8195)
@@ -39,9 +39,6 @@
#include "pub_tool_options.h" // VG_(clo_backtrace_size)
#include "pub_tool_threadstate.h" // VG_(get_pthread_id)()
-/* Include the drd_bitmap.c source file here to allow the compiler to */
-/* inline the bitmap manipulation functions called from this source file. */
-#include "drd_bitmap.c"
// Local functions.
@@ -89,14 +86,6 @@
s_segment_merging = m;
}
-__inline__ Bool IsValidDrdThreadId(const DrdThreadId tid)
-{
- return (0 <= (int)tid && tid < DRD_N_THREADS && tid != DRD_INVALID_THREADID
- && ! (s_threadinfo[tid].vg_thread_exists == False
- && s_threadinfo[tid].posix_thread_exists == False
- && s_threadinfo[tid].detached_posix_thread == False));
-}
-
/**
* Convert Valgrind's ThreadId into a DrdThreadId. Report failure if
* Valgrind's ThreadId does not yet exist.
Modified: trunk/exp-drd/drd_thread.h
===================================================================
--- trunk/exp-drd/drd_thread.h 2008-06-06 10:17:26 UTC (rev 8194)
+++ trunk/exp-drd/drd_thread.h 2008-06-06 10:18:24 UTC (rev 8195)
@@ -92,7 +92,6 @@
void thread_trace_context_switches(const Bool t);
void thread_trace_danger_set(const Bool t);
void thread_set_segment_merging(const Bool m);
-Bool IsValidDrdThreadId(const DrdThreadId tid);
DrdThreadId VgThreadIdToDrdThreadId(const ThreadId tid);
DrdThreadId NewVgThreadIdToDrdThreadId(const ThreadId tid);
@@ -154,6 +153,15 @@
ULong thread_get_danger_set_bitmap2_creation_count(void);
+static __inline__
+Bool IsValidDrdThreadId(const DrdThreadId tid)
+{
+ return (0 <= (int)tid && tid < DRD_N_THREADS && tid != DRD_INVALID_THREADID
+ && ! (s_threadinfo[tid].vg_thread_exists == False
+ && s_threadinfo[tid].posix_thread_exists == False
+ && s_threadinfo[tid].detached_posix_thread == False));
+}
+
static inline
DrdThreadId thread_get_running_tid(void)
{
|
|
From: <sv...@va...> - 2008-06-06 10:17:36
|
Author: bart
Date: 2008-06-06 11:17:26 +0100 (Fri, 06 Jun 2008)
New Revision: 8194
Log:
The run-splash2 script now works regardless from which directory it is started in.
Modified:
trunk/exp-drd/scripts/run-splash2
Modified: trunk/exp-drd/scripts/run-splash2
===================================================================
--- trunk/exp-drd/scripts/run-splash2 2008-06-05 13:47:15 UTC (rev 8193)
+++ trunk/exp-drd/scripts/run-splash2 2008-06-06 10:17:26 UTC (rev 8194)
@@ -75,8 +75,8 @@
# Script body
DRD_SCRIPTS_DIR="$(dirname $0)"
-if [ "${DRD_SCRIPTS_DIR}" = "." ]; then
- DRD_SCRIPTS_DIR="$PWD"
+if [ "${DRD_SCRIPTS_DIR:0:1}" != "/" ]; then
+ DRD_SCRIPTS_DIR="$PWD/$DRD_SCRIPTS_DIR"
fi
SPLASH2="${DRD_SCRIPTS_DIR}/../splash2"
@@ -110,6 +110,7 @@
# Water-sp 49 48 ? 49 183 34
#
# Hardware: dual-core Intel Xeon 5130, 1.995 MHz, 4 MB L2 cache, 4 GB RAM.
+# Software: Ubuntu 7.10 server, 64-bit (includes gcc 4.1.3).
cache_size=$(get_cache_size)
log2_cache_size=$(log2 ${cache_size})
|
|
From: Bart V. A. <bar...@gm...> - 2008-06-06 06:04:15
|
On Thu, Jun 5, 2008 at 11:19 PM, Dan Kegel <da...@ke...> wrote: > /data/dkegel/valgrind/exp-drd/drd_bitmap.c:58: multiple definition of `bm_new' > exp_drd_x86_linux-drd_bitmap.o:/data/dkegel/valgrind/exp-drd/drd_bitmap.c:58: > first defined here Hello Dan, Just rerun autogen.sh and configure and the above issue will disappear. Bart. |
|
From: Tom H. <th...@cy...> - 2008-06-06 02:57:43
|
Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-06-06 03:20:05 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 437 tests, 7 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 437 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Jun 6 03:39:34 2008 --- new.short Fri Jun 6 03:57:47 2008 *************** *** 8,10 **** ! == 437 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) --- 8,10 ---- ! == 437 tests, 7 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) *************** *** 14,16 **** none/tests/mremap2 (stdout) - helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc20_verifywrap (stderr) --- 14,15 ---- |
|
From: Tom H. <th...@cy...> - 2008-06-06 02:42:02
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-06-06 03:25:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 435 tests, 6 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-06-06 02:40:24
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-06-06 03:05:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 431 tests, 4 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-06-06 02:37:21
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-06-06 03:10:06 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 431 tests, 7 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 431 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Jun 6 03:23:46 2008 --- new.short Fri Jun 6 03:37:26 2008 *************** *** 8,10 **** ! == 431 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 431 tests, 7 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) *************** *** 14,15 **** --- 14,16 ---- none/tests/mremap2 (stdout) + none/tests/pth_cvsimple (stdout) helgrind/tests/tc18_semabuse (stderr) |
|
From: Tom H. <th...@cy...> - 2008-06-06 02:23:24
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-06-06 03:00:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 437 tests, 30 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Nicholas N. <nj...@cs...> - 2008-06-06 00:32:15
|
On Thu, 5 Jun 2008, Josef Weidendorfer wrote: > recently I noted that for the cache simulation of Cachegrind (and thus, also Callgrind) > there are situations where a line found in L1 will be evicted from L2 only, thus violating > the inclusion property. If you can support this (see example below), we either should change > the implementation (probably involving a slowdown), or fix the manual which states that this > is a inclusive cache simulation. > > For simplicity, suppose we have a 2-way associativity both in L1 and L2, and we have 3 > memory blocks of cache line size with addresses a1, a2, a3. Suppose that these addresses > map into the same set in L1 and L2. > > (1) Access to a1, then to a2. > Afterwards, the LRU access history list of the sets is (a2, a1). > (2) Access to a1. > This time, we get a L1 hit, and return directly from simulation. > The LRU list of L1 now is (a1, a2), and the one of L2 is still (a2, a1). > (3) Access to a3. > This is a L1 miss, evicting cache line for a2 from L1, and also a L2 miss, > evicting the cache line for a1 in L2. > > Now, the cache line for a1 is evicted from L2, but still in L1. > > For correct simulation, we should forward the L1 hit in (2) also to L2, such that > the LRU list of L2 can be updated and matches the one of the L1 afterwards. Thus, > the LRU list after (3) would have been (a3, a1) both for L1/L2. Ie. a2 would have > been evicted both from L1 and L2. > > This also changes the event numbers in contrast to an inclusive cache: a further > access to a2 will give a L2 hit in the current simulation, but would have been > a L2 miss in the correct inclusive simulation. > > Probably the above situation is very rare, but I am sure that one could construct a > similar example even with higher associativity in L2 than L1, leading to different > event numbers between Cachegrinds simulation and a real inclusive cache. > > Do I miss something here? In short: when an L1 hit occurs, the L1 MRU list is updated, but the L2 MRU list is not, right? Hmm, I think your analysis is correct. I hope anyone that is using Cachegrind for serious analysis is plugging their own cache simulator into it. Making the simulation correct so that it is properly inclusive seems like a good thing to do. Would you be able to work up a patch that does this, and see what the performance effect is for Cachegrind? Nick |