In response to Bill Moran <[EMAIL PROTECTED]>:
>
> [I sent this to questions@ yesterday and have yet to get a response. I
> suspect it may be a little more technical than [EMAIL PROTECTED]
>
> uname -a
> FreeBSD db00.lab00 6.2-BETA3 FreeBSD 6.2-BETA3 #1: Fri Dec 8 09:27:37 EST
> 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DB-2850-amd64 amd64
>
> sysctl kern.ipc.shmmax=2200000000
> kern.ipc.shmmax: 2100000000 -> -2094967296
>
> Looks like an unsigned 32-bit int. That doesn't seem to scale as well as
> would be expected on 64-bit arch (or PAE for that matter).
>
> Is this a mistake, or intentional? I'm working with some big memory
> systems, and I sure would like to allocate more than 2G for PostgreSQL
> to use ...
Responding/following up on my own post ...
Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Bill's guess is probably right, so someone needs to go over the sysv
> ipc code and make it 64-bit capable.
OK. Looks like I've volunteered. I know little to nothing about the
internals of the sysv system, so some of this may look pretty
uninformed.
First run through finds src/sys/sys/shm.h, which has a few obvious
data structures that need updated:
struct shmid_ds {
struct ipc_perm shm_perm; /* operation permission structure */
int shm_segsz; /* size of segment in bytes */
pid_t shm_lpid; /* process ID of last shared memory op */
pid_t shm_cpid; /* process ID of creator */
short shm_nattch; /* number of current attaches */
time_t shm_atime; /* time of last shmat() */
time_t shm_dtime; /* time of last shmdt() */
time_t shm_ctime; /* time of last change by shmctl() */
void *shm_internal; /* sysv stupidity */
};
struct shminfo {
int shmmax, /* max shared memory segment size (bytes) */
shmmin, /* min shared memory segment size (bytes) */
shmmni, /* max number of shared memory identifiers */
shmseg, /* max shared memory segments per process */
shmall; /* max amount of shared memory (pages) */
};
However, looking at some function declarations in that same file:
int shmget(key_t, size_t, int);
I appears as if those values should have been size_t all along. I'm
_assuming_ that the return value is an identifier and not a memory
address, which is what the docs seem to imply.
So, my first thought is that all the int values in those structures
should be changed to size_t. If I understand the use of that type
correctly, it should always be the native word size on the architecture,
but will that make this work for PAE as well, or should those be
changed to uint64_t so they're 8 bits wide on all archs?
Once I understand a little more about what the correct type is for
those, I'll start looking for where they're used ...
--
Bill Moran
Collaborative Fusion Inc.
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
