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
(2) |
2
(4) |
3
(1) |
4
(7) |
5
|
|
6
|
7
(4) |
8
|
9
(3) |
10
(6) |
11
(13) |
12
(6) |
|
13
(1) |
14
|
15
(1) |
16
|
17
(4) |
18
(3) |
19
(5) |
|
20
(5) |
21
(5) |
22
(5) |
23
(6) |
24
|
25
(1) |
26
(1) |
|
27
(1) |
28
(4) |
29
(5) |
30
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2016-11-17 22:09:28
|
On Tue, 2016-11-15 at 19:30 +0100, Petar Jovanovic wrote: > Hi Philippe, > > > * helgrind test seems to succeed (more?) systematically, but takes a > lot > > longer (around one minute, burning a lot of CPU, against about 10 > > seconds unpatched). > > This is a bit unusual. I have seen awfully long executions with the > current > trunk (i.e. without any patches) on my multicore x86 server ( > Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz). > > $ time perl tests/vg_regtest helgrind/tests/bar_bad.vgtest > bar_bad: valgrind -q ./bar_bad > > == 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 > stdoutB failures, 0 post failures == > > > real 19m57.592s > user 20m5.572s > sys 0m1.680s I think these (sometimes) very long execution times are due to the default (unfair) way the valgrind scheduler works, which might cause starvation. Adding options --fair-sched=try for the 3 */tests/bar_bad*vgtest should ensure a reasonable bounded time. Philippe |
|
From: Philippe W. <phi...@sk...> - 2016-11-17 21:28:28
|
On Tue, 2016-11-15 at 19:30 +0100, Petar Jovanovic wrote: > Would the following one work for you? > > https://bugsfiles.kde.org/attachment.cgi?id=102247 > > bar_bad fails consistently on some systems and it would be good if we > could > find some solution for it. Yes, that would be really good. And your last patch looks to be on the good way. I have run: perl tests/vg_regtest --loop-till-fail helgrind/tests/bar_bad*vgtest drd/tests/bar_bad*vgtest and it has done now already 60 tests without failing or blocking. So, seems nice ... Philippe |
|
From: Philippe W. <phi...@sk...> - 2016-11-17 20:01:10
|
On Thu, 2016-11-17 at 11:25 -0800, Carl E. Love wrote:
> I have put debug statements into this code for both the inner and outer
> valgrind trees. The value returned by VG_MINIMAL_SETJMP() is 1 for the
> outer Valgrind and thus have_isa_2_07 is set to False. For the inner
> valgrind, the return value is 0 and we do not change have_isa_2_07.
>
> I have studied up a little on the setjump/longjump stuff. At this point,
> I don't know why they don't seem to work in the inner Valgrind. I was
> wondering if anyone had any insight it doesn't work on the inner?
I am guessing that VG_MINIMAL_SETJMP is in fact working.
I am guessing that the difference is:
* the outer checks that a capability is (or is not) supported by
trying an instruction.
If the instruction is not supported, a LONGJMP will happen.
On Power 7, that is what happens in the outer, as the outer runs
on the real (hw) cpu.
* When the inner runs, it runs on the CPU simulated by the outer.
Now, if the outer just executes this instruction without checking
the hw cap of the physical cpu (and runs the IR code retranslated
in other instructions), then the inner believes it is on a different
cpu than the hw cpu.
More generally, we might improve on the way to control the virtual
cpu provided by valgrind.
For example, we might imagine to have some command line flags
to specify what 'hw features' to simulate.
Of course, when translating to real instructions, only the really
available hw instructions can be generated (which means that it might
not be possible to accept all instructions in the virtual cpu).
Philippe
|
|
From: Carl E. L. <ce...@us...> - 2016-11-17 19:25:29
|
Julian, Valgrind developers:
Philippe found an issue on Power when self hosting Valgrind. The issue
shows up on Power 7 which does not support ISA 2.07.
The issue is we do a check to see if the run time check to see what the
hardware supports matches what the system says.
in short in initimg-linux.c, about line 736 we check if the auxv vector
has the ISA 2.07 flag set and compare that with the vex_archinfo->hwcaps
that was calculated by valgrind.
The a_val member of this entry is a bit map of hardware
capabilities. Some bit mask values include:
PPC_FEATURE2_ARCH_2_07 0x80000000
PPC_FEATURE2_HAS_HTM 0x40000000
PPC_FEATURE2_HAS_DSCR 0x20000000
PPC_FEATURE2_HAS_EBB 0x10000000
PPC_FEATURE2_HAS_ISEL 0x08000000
PPC_FEATURE2_HAS_TAR 0x04000000
PPC_FEATURE2_HAS_VCRYPTO 0x02000000
*/
auxv_2_07 = (auxv->u.a_val & 0x80000000ULL) == 0x80000000ULL;
hw_caps_2_07 = (vex_archinfo->hwcaps & VEX_HWCAPS_PPC64_ISA2_07)
== VEX_HWCAPS_PPC64_ISA2_07;
/* Verify the PPC_FEATURE2_ARCH_2_07 setting in HWCAP2
* matches the setting in VEX HWCAPS.
*/
The issue is on the inner valgrind vex_archinfo->hwcaps has the bit set
for VEX_HWCAPS_PPC64_ISA2_07.
The vex_archinfo->hwcaps value is set in coregrind/m_initimg/machine.cat
about line 1167
/* Check for ISA 2.07 support. */
have_isa_2_07 = True;
if (VG_MINIMAL_SETJMP(env_unsup_insn)) {
have_isa_2_07 = False;
} else {
__asm__ __volatile__(".long 0x7c000166"); /* mtvsrd XT,RA */
}
I have put debug statements into this code for both the inner and outer
valgrind trees. The value returned by VG_MINIMAL_SETJMP() is 1 for the
outer Valgrind and thus have_isa_2_07 is set to False. For the inner
valgrind, the return value is 0 and we do not change have_isa_2_07.
I have studied up a little on the setjump/longjump stuff. At this point,
I don't know why they don't seem to work in the inner Valgrind. I was
wondering if anyone had any insight it doesn't work on the inner?
Carl Love
On Sat, 2016-11-12 at 11:45 +0100, Philippe Waroquiers wrote:
> Hello Carl,
>
> I am busy investigating a strange behaviour (loss of performance)
> on ppc64 (callgrind tool), probably due to revision r16121.
>
> Doing that, I wanted to do valgrind self hosting
> (see README_DEVELOPERS for more info).
>
> When doing that, the inner valgrind asserts on the assert
> that I have commented below
> I can of course commit a fix that the below assert is not
> checked in an inner setup, but as I do not understand much
> of the below, it would be nice if you could investigate ?
> (no urgency of course, as the bypass is ok for now)
> Thanks
>
> Philippe
>
>
> Index: coregrind/m_initimg/initimg-linux.c
> ===================================================================
> --- coregrind/m_initimg/initimg-linux.c (revision 16120)
> +++ coregrind/m_initimg/initimg-linux.c (working copy)
> @@ -739,7 +739,7 @@
> /* Verify the PPC_FEATURE2_ARCH_2_07 setting in HWCAP2
> * matches the setting in VEX HWCAPS.
> */
> - vg_assert(auxv_2_07 == hw_caps_2_07);
> +// vg_assert(auxv_2_07 == hw_caps_2_07);
> }
>
> break;
>
>
|