[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this
From:       Jamie Lokier <jamie () shareable ! org>
Date:       2003-08-31 22:49:37
[Download RAW message or body]

David S. Miller wrote:
> On Fri, 29 Aug 2003 16:05:21 -0700
> Mike Fedyk <mfedyk@matchmail.com> wrote:
> 
> > Does this mean that userspace has to take into consideration that the isn't
> > coherent for adjacent small memory accesses on sparc?  What could happen if
> > it doesn't, or does it need to at all?
> 
> For shared memory, we enforce the correct mapping alignment
> so that coherency issues don't crop up.
> 
> How does this program work?  I haven't taken a close look
> at it.  Does it use MAP_SHARED or IPC shm?

It uses POSIX shared memory and (necessarily) MAP_SHARED, which
doesn't constrain the mapping alignment.

I had wondered if some kernels used page faults to maintain coherence
between multiple shared mappings of the same file.  It's one of the
things the program checks, and I have seen it mentioned on l-k, which
made me think it might be implemented.  None of the results for any
architecture show it, though.

If userspace does create multiple shared mappings at non-coherent
offsets, what is the recommended method for switching between
accessing one page (or page cluster?) and accessing the other.  Is it
msync(), a special system call to flush parts of the data cache, a
machine instruction, or something else?

Thanks,
-- Jamie



ps. The program has code to try IPC shm instead.  Change "#ifdef
SHM_DIR_PREFIX" in __page_alias_map to "#if 0", and add
-DHAVE_SYSV_SHM to the GCC command line.  It should fail the same test
sizes with a different message.
-
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/
[prev in list] [next in list] [prev in thread] [next in thread]