On 05/11/2011 07:58 PM, JD wrote: > mlock(2): > int mlock(const void *addr, size_t len); > can lock user virtual pages to memory (if user has the privileges). > But when it comes to a file, you have no way of knowing the VA of the > pages in > which a file is stored, so you will not be able to call mlock(2) with > the right VA. Actually if used properly mlock works pretty well - see the LVM2 example I gave. Just use mmap to map the region of interest into the process address space (obviously it will need to fit but not a problem on a real computer ;). There can be surprises however and this is the reason that LVM's use is "fancy"; the fedora locale-archive (part of glibc-common) is quite large today to contain strings for the wide range of supported languages in Fedora. On my f15 desktop it's around the 96M mark: $ pmap $$ | grep locale-archive 00007f140b684000 96836K r---- /usr/lib/locale/locale-archive On very low memory systems this can lead to problems with apps that want to lock all pages of their address space into RAM (oom kills etc.). LVM avoids this by blacklisting certain mapped files from mlock operations (see cvsweb link, _memlock_maps(), _maps_line() and _blacklist_maps[]). > Furthermore, a file is not necessarily all brought into memory IN CONTIGUOUS > VIRTUAL PAGES of the system's filecache. So, obviously, mlock would not > help. Does not matter. We're talking process address space not page cache. Regards, Bryn. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
