-----Original Message----- From: Mike Kearey [mailto:mkearey@xxxxxxxxxx] Sent: Wednesday, February 28, 2007 11:23 PM To: General Red Hat Linux discussion list Subject: Re: Locking shared memory Allen, Jack wrote: <snip> > =================================================== > All: > Some additional information. As I have said when I try to lock > the second shared memory address via mlock(addr,size) it fails. I have > been assuming incorrectly that that errno of ENOMEM meant I was hitting > a limit. So I decided to try some other things to make sure. Using the > same 512MB overall size for the amount of shared memory I allocated it > in 32MB segments, which gives me 16 segments. I was able to lock all but > the last segment. This would again sound like I had hit a limit. My next > test was to use 1024MB overall and use 64MB segments, which give 16 > segments also. I was able to lock all but the last segment again. So > this means I was able to lock 960MB with no problem. Therefore it does > not seem to be limit of the maximum amount I can lock, because the last > test exceeded the first test by 704MB. So I suspect errno may be > indicating the wrong reason for the failure. I think it has something to > do with an address boundary or page alignment. > > Does anyone have any thoughts. > > Thanks: > Jack Allen > > G'day again Jack, I have looked at the man page for mlock on RHEL4 . It mentions the following : "The mlock() function shall cause those whole pages containing any part of the address space of the process starting at address addr and continuing for len bytes to be memory-resident until unlocked or until the process exits or execs another process image. The implementation may require that addr be a multiple of {PAGESIZE}." So it looks likely that the memory needs at least to be PAGESIZE aligned. I also looked at the man page for mlock from Fedora Core 6, it seems to be a little more verbose and provides a clear explanation: " mlock() and mlockall() respectively lock part or all of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area. munlock() and munlockall() perform the converse operation, respectively unlocking part or all of the calling process's virtual address space, so that pages in the specified virtual address range may once more to be swapped out if required by the kernel memory manager. Memory locking and unlocking are performed in units of whole pages. ..., LINUX NOTES Under Linux, mlock() and munlock() automatically round addr down to the nearest page boundary. However, POSIX.1-2001 allows an implementation to require that addr is page aligned, so portable applications should ensure this. Limits and permissions In Linux 2.6.8 and earlier, a process must be privileged (CAP_IPC_LOCK) in order to lock memory and the RLIMIT_MEMLOCK soft resource limit defines a limit on how much memory the process may lock. Since Linux 2.6.9, no limits are placed on the amount of memory that a privileged process can lock and the RLIMIT_MEMLOCK soft resource limit instead defines a limit on how much memory an unprivileged process may lock. " Cheers, Michael ============================================== Michael: Thanks for the information. After I posted the last update I did some more testing related to page boundaries. I did ps = sysconf(_SC_PAGESIZE) which set ps to 4096. I then logged the results of (addr % ps) for each address and (size % ps) for each size before calling mlock(addr,size). Both calulations logged 0, which means the address starts on a page boundary and ends on a page boundary. So I am still at a loss as to why only the last segment fails. Any more thoughts or things to check from you or anybody? Thanks: Jack Allen -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
