lkml.org 
[lkml]   [2003]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.091 / U:0.332 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site