Prev: how to handle socket timeout?
Next: gdb vs fortran RTL -- fight for SIGSEGV
From: Scott Lurndal on 26 Jun 2008 18:23
phil-news-nospam(a)ipal.net writes:
>On Sat, 21 Jun 2008 14:55:27 -0700 (PDT) guenther(a)gmail.com <guenther(a)gmail.com> wrote:
>
>| If my memory serves, the real exception was HP-UX on PA-RISC, where
>| there was NO SUPPORTED METHOD to make a change visible via write()
>| visible to a shared mapping. Completely unmapping the file and
>| remapping it could leave you with old data in the mapping! There were
>| other horrible restrictions on shared mappings (they had to have the
>| same VM address *in all processes*) that made using mmap() there
>| completely unworkable for files that needed to grow while being
>| shared.
>
>My understanding of these limitations is that it is a hardware issue with
>regard to cache line size being larger than a page size.

No, it is because the PA-RISC cache cannot handle virtual aliases
to the same physical memory. Thus, all processes need to use the
same virtual address for the shared memory segment (or mmap(MAP_SHARED)).

Read up on virtually addressed cache architectures, and their limitations.

Then you'll get into cache coloring and all kinds of silly mechanisms
designed to accomodate the defects of a virtually addressed cache.

scott
From: phil-news-nospam on 26 Jun 2008 22:54
On Thu, 26 Jun 2008 22:23:51 GMT Scott Lurndal <scott(a)slp53.sl.home> wrote:
| phil-news-nospam(a)ipal.net writes:
|>On Sat, 21 Jun 2008 14:55:27 -0700 (PDT) guenther(a)gmail.com <guenther(a)gmail.com> wrote:
|>
|>| If my memory serves, the real exception was HP-UX on PA-RISC, where
|>| there was NO SUPPORTED METHOD to make a change visible via write()
|>| visible to a shared mapping. Completely unmapping the file and
|>| remapping it could leave you with old data in the mapping! There were
|>| other horrible restrictions on shared mappings (they had to have the
|>| same VM address *in all processes*) that made using mmap() there
|>| completely unworkable for files that needed to grow while being
|>| shared.
|>
|>My understanding of these limitations is that it is a hardware issue with
|>regard to cache line size being larger than a page size.
|
| No, it is because the PA-RISC cache cannot handle virtual aliases
| to the same physical memory. Thus, all processes need to use the
| same virtual address for the shared memory segment (or mmap(MAP_SHARED)).

So what happens when the same physical memory address exists in two different
segment table locations?


| Read up on virtually addressed cache architectures, and their limitations.

I have. It sounds like the PA-RISC is weird. Virtual to real translation is
a basic lookup. But perhaps PA-RISC does this differently and uses some kind
of associative memory where the real address maps to a virtual address and it
scans the table to find which entry has that virtual address?


| Then you'll get into cache coloring and all kinds of silly mechanisms
| designed to accomodate the defects of a virtually addressed cache.

It's not hard if the designers keep the caching design simple.

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
First  |  Prev  | 
Pages: 1 2
Prev: how to handle socket timeout?
Next: gdb vs fortran RTL -- fight for SIGSEGV