[Valgrind-developers] Re: CVS: valgrind/coregrind vg_from_ucode.c,1.23,1.24 vg_include.h,1.101,1.102

[Julian S. <js...@ac...>]

[replying to 2 messages at once here]

> My desktop machine is a 1.8GHz P4, but its running 2.5, so some things
> don't work.  Not sure that oprofile is set up, but it shouldn't be hard
> to do.
>
> The machine I do most development on is a 600MHz P3 laptop (mostly
> because I seem to do a lot of it on the train).

Wow, you have a train commute in which you can actually sit down so as
to use the laptop.  Cor.  All the folks who commute here <-> London
(55 miles each way) by train would be jealous.  Fortunately not me.


> I also followed up your mention of writing within 1k (or 2k) of code in
> the trace cache, and it does seem pretty dire.  It looks like writing to
> memory within a 1k sector of something in the trace cache can cause the
> whole trace cache to be dumped.  [...]

That would also mean that P4 does poorly when running all sort of other
dynamic code generation systems (java jits etc) and so if that's the
case, which it could well be, there may be stuff out on the web which
documents it.  I'll have a look.

One way to assess this is to run something like the simple loop prog
I sent in earlier mail, and/or bzip2, which compute for a long time
without generating any/many translations.  If it's only TC flushes
that hammer us on P4, then the ratios for those progs should match
more closely the PIII ratios.  I might look at this when I get a mo.


> > You'll see I just committed a simple hack which seems to substantially
> > mitigate the INCEIP thing; it's a combination of your partial-write idea
> > and my always-write-never-add idea.
>  
> So you found that doing the SYNCEIP only-update-when-someone-needs-EIP 
> wasn't worthwhile? 

It hardly seemed to make any difference, over several runs of several
programs.  What is committed now just does one write per INCEIP.  I also
experimented with a version which did analysis to skip redundant INCEIPs
-- in which case the results would have been very similar to your
SYNCEIP scheme -- and it made only minor improvements compared with 
the improvement had from turning read-modify-write (INCEIP) into write 
(SETEIP, in effect).


> I have a partial patch to do something like this.  I hijacked VG_(new_emit)
> by adding the args (Bool emu_flags, FlagSet uses, FlagSet sets).  emu_args
> [...]
> selectively load and save flags.  I haven't got very far with this yet.

Perhaps hang fire on this a couple of days.  Last night I started a scheme
similar to your FPU-liveness thing for eflags, and it got as far as 
delivering me a constant stream of segfaults before I had to give up and
sleep.  I'll try and get it working tonight.

J