Re: [Boost-users] [Interprocess] Page default
To elaborate on Ion's remarks, ALL virtual memory in user space in windows is backed by the page file, and ALL file I/O is memory mapped, the only difference being virtual memory is backed by the page file rather than a specific named file in the file system. Your inter process memory is just as likely to be in physical memory as any other data. So most likely this is not the cause of your performance issue, unless memory is so tight that your entire process working set is continually thrashing. Dan -----Original Message----- From: Ion Gaztañaga [igaztanaga@gmail.com<mailto:igaztanaga@gmail.com>] Sent: Wednesday, July 24, 2013 06:48 PM Eastern Standard Time To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Interprocess] Page default El 18/07/2013 14:45, Oodini escribió:
Hello,
I use Boost.Interprocess on Windows 2003 Server.
I am experiencing performances troubles. I am trying to understand what happens, and arrived on Microsoft web pages.
I seems that on Windows, shared memory is implemented only through mapped files, and that only a portion of the shared memory is physically in the RAM (this limited number of pages is called "working set").
The Windows API provides some functions for this working set : http://msdn.microsoft.com/en-us/library/windows/desktop/cc441804%28v=vs.85%2...
I would have liked Interprocess wraps the functions GetProcessMemoryInfo() and SetProcessWorkingSetSize(), so that the full shared memory is put in RAM.
Inteprocess can't do that because it's a portable library and POSIX systems don't know what a working set is. You can perfectly call those functions yourself as you don't need any internal Interprocess data to call them. Although shared memory is never guaranteed to be in RAM, you don't any any guarantee with your "process memory" (if memory pressure is detected the OS can swap you heap and/or executable pages to the swap file to free some RAM for other processes). Best, Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
To elaborate on Ion's remarks, ALL virtual memory in user space in windows is backed by the page file, and ALL file I/O is memory mapped, the only difference being virtual memory is backed by the page file rather than a specific named file in the file system. Your inter process memory is just as likely to be in physical memory as any other data. So most likely this is not the cause of your performance issue, unless memory is so tight that your entire process working set is continually thrashing.
Well, my program previously loads the data in "normal" RAM, and I ddidn't have any problems. Since I use the shared memory, I do experiencing troubles. PS : my data are about 12 Gb big, and I have 24 Gb of RAM on my system.
El 02/08/2013 11:52, Oodini escribió:
To elaborate on Ion's remarks, ALL virtual memory in user space in windows is backed by the page file, and ALL file I/O is memory mapped, the only difference being virtual memory is backed by the page file rather than a specific named file in the file system. Your inter process memory is just as likely to be in physical memory as any other data. So most likely this is not the cause of your performance issue, unless memory is so tight that your entire process working set is continually thrashing.
Well, my program previously loads the data in "normal" RAM, and I ddidn't have any problems. Since I use the shared memory, I do experiencing troubles.
PS : my data are about 12 Gb big, and I have 24 Gb of RAM on my system.
As in windows shared memory is emulated using mapped files, you can try to use windows_managed_shared_memory instead. The interface is a bit different (you don't unlink that shared memory, it's destroyed when the last attached process dies), but that will use native shared memory (memory is backed from the system pagefile) and maybe it might perform better. Best, Ion
Hello, I finally have the time to come back on this task. :) Thanks again for your previous answers. The problem seems come from the mapping process after the call to get_adress(). I am confronted to "soft" page defaults.
participants (5)
-
Ion Gaztañaga -
Kelly, Dan -
Oodini