|
From: Jeremy F. <je...@go...> - 2004-09-08 21:11:51
|
On Thu, 2004-09-02 at 11:23 +0100, Julian Seward wrote: > One point to bear in mind is that the conversation that followed > appeared to be silently predicated on the assumption that Linux is > the only kernel we're interested in. We have to think beyond that: > I would love to make V available for MacOSX, and I bet (eg) the > OpenBSD folks would love to get their hands on an x86-openbsd > variant of Valgrind. Indeed, once Nick's current commit set goes > in, one interesting experiment would be to try an openbsd port. > Or freebsd (already exists) or netbsd. I don't think anything here is particularly kernel-dependent. The prerequisite is that there's an mmap syscall which allows us to define the placement of things in the address space. That's not a big ask. > Let's just forget about big-bang shadow allocation. It causes a whole > bunch of problems, we're not using it at the moment, and we don't have > a clear picture of where the cycle-level costs of shadow memory come > from anyway. For example, if shadow memory really kills us because > it jacks up the D1/L2 cache miss rates, then it's going to do so > regardless of the address translation scheme in use. Well, if we use direct map, then we're using the CPU's TLB rather than its D caches, so the tradeoff changes. And we're taking advantage of a CPU hotpath, which is presumably well optimised. "Manual" table indirects have locality patterns which match the client's memory access, so there isn't a huge increase in cache pressure. (ie, there's a doubling because of the data+shadow, but the table accesses only add 1 line per pagetable level.) The manual scheme adds I cache pressure linear to the number of table levels, if the table indirection is inlined. > > 4. Maybe make the --pointer-check=no change, if it seems useful. > > Well, I like the fact that currently the client can't trash V. > > Another thing to consider is how to achieve this portably, on > non-x86s. If the client address space is contained entirely in > 0 .. N-1, and N is a power of two, ANDing is obviously a cheap > solution. If the machine contains a scalar 'min' insn, then > we can do this cheaply for any N. There's the question of whether you simply want to prevent the client hitting Valgrind (by ANDing off the address bits), or actually detect the case and raise an error. J |