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
(10) |
3
(5) |
|
4
(12) |
5
(12) |
6
(15) |
7
(17) |
8
(13) |
9
(18) |
10
(10) |
|
11
|
12
(2) |
13
(20) |
14
(16) |
15
(17) |
16
(19) |
17
(17) |
|
18
(14) |
19
(12) |
20
|
21
(5) |
22
(12) |
23
(10) |
24
(1) |
|
25
|
26
(2) |
27
|
28
(2) |
29
|
30
(1) |
31
(2) |
|
From: stavros k. <ska...@gm...> - 2014-05-31 23:03:57
|
>I suppose the worst case is random access on a huge array.
Close enough! The worst case among the programs tried was access on huge
array but it was not random. I used a variation of the program presented by
Nicholas Nethercote is his PhD thesis which has as follows:
#define SIZE (2048)
int main(void){
int h,i,j;
static int a[SIZE][SIZE];
for(h=0;h<10;h++)
for(i=0;i<SIZE;i++)
for(j=0;j<SIZE;j++)
a[i][j]=0;
return 0;
}
>The usage of cachegrind is to find bottlenecks related to the cache
>hierarchy.
>I wonder if L2 miss behavior really helps a lot in this regard.
I agree with that. It would make results slightly more accurate, but it
does not contribute significantly.
It could be added as an option to help the very curious.
>Does your simulation run L2/L3 accesses then with physical addresses?
I am not sure I understand what you mean here. If I understand correctly,
you are asking if virtual addresses are translated to physical ones before
CPU cache simulation (the simulation Cachegrind already provided) takes
place? and as a result to simulate the CPU caches using physical addresses
instead of virtual?
If that was the question, then the answer is no. The TLB simulator is not
run before CPU cache simulation, thus, physical addresses are not used
instead of virtual ones to simulate the CPU cache (L1,L2,L3).
>To understand whether good/bad TLB behavior has an impact on
>performance, I think
>one should be able to see whether page walks resulting from TLB misses
>themself
>can be served from cache or not.
>I suppose your simulation does not
>include this?
the TLB extension is only concerned with the TLB and does not interfere
with CPU caches at all. Therefore, it does not provide results that concern
both the TLB and the CPU caches together.
I will try and see if I can get permission to provide my dissertation where
I think a good description of the capabilities and the characteristics of
the extensions can be found.
Stavros
|
|
From: Ivo R. <iv...@iv...> - 2014-05-31 18:58:50
|
I would like to ask what are the possibilities of intercepting a write to a memory address under valgrind, regardless of a tool currently used. For the valgrind port to Solaris, I am investigating whether it is possible to intercept a write to an address and replace it with some hook in the syscall machinery. Every thread has its own address (it is per thread) and the address is not known prior to running the program - it is known before the thread performs some synchronization operation. In particular, I cannot modify source code which contains the write. In x86 assembly it is simple 'movl' from register to a memory location. ---------------------- Motivation is the following: Solaris contains a special libc/kernel synchronization mechanism. A piece of per-thread memory is shared between libc and kernel. It is used for various purposes, one is for 'block-all-signals' flag. Libc prior to certain synchronization operations writes to that memory indicating to the kernel that all signals should be blocked. Eventually a regular syscall is invoked; kernel detects the flag, disables all signals and clears the flag. The problem here is that setting this flag by libc bypasses Valgrind's signal machinery which gets confused by the fact that all signals are disabled in kernel without knowing it (which would be no problem should this went through regular syscall sigprocmask & friends). ---------------------- Thanks in advance for any pointers and suggestions. I. |