Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this
From: Jamie Lokier
Date: Mon Sep 01 2003 - 05:06:46 EST
- Next message: Jamie Lokier: "Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this"
- Previous message: Edward Wildgoose: "Curious problem with network driver on 2.6 (no UDP)"
- In reply to: David S. Miller: "Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this"
- Next in thread: David S. Miller: "Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
David S. Miller wrote:
> Why do you need the same piece of data mapped to multiple places
> in the first place, and why at specific addresses? It's purely an
> optimization of some sort, right?
Right. It's a circular buffer for signal processing: DSP code sees
contiguous ascending addresses. The multiple maps mean we don't have
to copy the contents of the buffer back to the start periodically, nor
mask the offset into the array on each memory access, nor write
extra-complicated DSP code which can handle split regions.
It's an optimisation, it works well on some architectures and on
others it's not worth it. On those, I just copy - it keeps the DSP
code fast and simple.
> > Well, my code has no bug because I do run-time tests to see what
> > rubbish the architecture gave me. As we see, they work :)
>
> It doesn't work in just the right set of circumstances, if interrupts
> arrive at just the right moment it might flush the bad aliases out
> of the cache via displacement during your 'check' phase.
>
> Then during your actual computation you can hit the aliasing problem
> silently.
To fool the coherence test, interrupts would need to arrive in a 2
instruction window, at least 8192 times. It is possible, but unlikely
except in pathological situations.
Of course if you make mmap() return EINVAL then it cannot possible fail :)
> I'd suggest instead to hardcode the SHMLBA stuff into your sources.
How? SHMLBA is a run time value on the Sparc; I have no idea how
to work it out.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Next message: Jamie Lokier: "Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this"
- Previous message: Edward Wildgoose: "Curious problem with network driver on 2.6 (no UDP)"
- In reply to: David S. Miller: "Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this"
- Next in thread: David S. Miller: "Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]