Date: Tue, 10 Dec 1996 11:03:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: scrappy@hub.org (Marc G. Fournier) Cc: hackers@FreeBSD.ORG Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <199612101803.LAA04496@phaeton.artisoft.com> In-Reply-To: <Pine.NEB.3.95.961209194502.12999J-100000@hub.org> from "Marc G. Fournier" at Dec 9, 96 07:56:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> that I don't know if its too be expected, or if I've screwed something
> up...
Administrative limit because of address space crowding... just like
the limit on segment size. You can override as necessary, and
rebuild a kernel. However, I would suggest you use mmap instead,
if possible.
> ----
> #define MAXMESGDATA 2048
>
> typedef struct {
> int mesg_len;
> char mesg_data[MAXMESGDATA];
> } Mesg;
> ----
WARNING!
When you map a shared memory region or file into an address space, the
cache unification and the x86 page protection mechanism forces the
mapping to be in chunks of 4k.
This basically means that you are overlapping your regions here. The
first region, if it starts on a 4k boundry (which it will, according
to your code) will map the first 4k page at the start address. The
second will map 8k, since it spans a 4k boundry: the first 4k, followed
by the next 4k. It will be mapped at a different address.
And so on, based on crossing conditions of 4k boundries.
It would be much better to mmap a contiguous area, where each message
fills up exactly 4k (even if you need pad to do it) and make sure the
messages are on 4k boundries to ensure seperate protection domains.
This is true, even if you use SVR4 primitives...
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612101803.LAA04496>