RE: Locking shared memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

-----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

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux