Rupesh Bhurke

Hello,

I am working on a project that needs reserving physical memory (100MB). Can anybody show me how I can achieve that. If you can provide a code sample, that will be great !

Best Regards,
Rupesh H Bhurke




Re: Visual C++ General Reserve Physical Memory

einaros

Your question is too vague to be answered accurately. You should specify your platform, environment, and reason for attempting to allocate anything.

A quick example on how to allocate 100 MB of virtual memory follows. As basic as this is, however, it isn't non-pageable or anything like that, so it's not guaranteed to be in physical memory at all times.

char* myBuffer = new char[100485760];
// do something with the buffer
delete myBuffer;






Re: Visual C++ General Reserve Physical Memory

aao123

Please specify what does it mean "reserve" memory



Re: Visual C++ General Reserve Physical Memory

Rupesh Bhurke

Oh !

I am very so sorry for being absurdly vague.

I am working on Windows-XP. My target platforms are Windows-XP & Windows Vista.
It is a MPEG2 DirectShow muxer that I am working on. I want to make sure that when my filter comes into memory it should have:

1. 100 MB of Physical Memory (non-pageable memory) or it can gracefully shutdown.
2. Once it has got hold of memory windows should not allocate that physical memory to any other application till my filter releases it.

So that's about it.








Re: Visual C++ General Reserve Physical Memory

einaros

Use VirtualAlloc and VirtualLock. There's an example at http://msdn2.microsoft.com/en-us/aa366549.aspx.




Re: Visual C++ General Reserve Physical Memory

Rupesh Bhurke

Hi !

Thank you for the link but I have tried this also.

My Observations are:

1. VirtualAlloc() with MEM_PHYSICAL does not work for values more than 144KB.
2. If we dont use VirtualAlloc( MEM_PHYSICAL ) We can use VirtualLock later on but even that fails.
3. PAGE_GUARD does not guarantee that my allocated memory will remain untouchable.

Please let me know if there is any other way






Re: Visual C++ General Reserve Physical Memory

einaros

Rupesh Bhurke wrote:

1. VirtualAlloc() with MEM_PHYSICAL does not work for values more than 144KB.

Use SetProcessWorkingSetSize, as the VirtualLock docs specify.

Rupesh Bhurke wrote:

2. If we dont use VirtualAlloc( MEM_PHYSICAL ) We can use VirtualLock later on but even that fails.

There's no need to specify MEM_PHYSICAL. In fact it shouldn't be used, unless you also specify MEM_RESERVE, and no other options.

Rupesh Bhurke wrote:


3. PAGE_GUARD does not guarantee that my allocated memory will remain untouchable.

That sounds unlikely. How have you confirmed this






Re: Visual C++ General Reserve Physical Memory

aao123

I am guessing that what you are looking for kind of goes against Windows memory management philosophy. I believe the behavior you are looking for is reserved for drivers, but even then 100 MB might be a problem. Look at DDK something like IoAllocateIrp. If I may offer my opinion, Id like to urge you to reconsider your approach. Unlike the popular believe memory is not cheap and it is defiantly finite resource. Forcing some memory be exclusively yours will limit other programs and create inconvenience for your user.





Re: Visual C++ General Reserve Physical Memory

Rupesh Bhurke

Hi einaros !

Thank you for your suggestions but I've run out of options. I mean I have already tried
SetProcessWorkingSetSize but does not seem to work.

Anyways, I am trying for some other aproach. If it's successful I will post it here. Till then I'll keep thread open.

Thank you everybody who came forward to guide me.

Rupesh




Re: Visual C++ General Reserve Physical Memory

Rupesh Bhurke

I guess you are right !

I'll certainly try to figure out some other way. I'll post it here. till then thread will be kept open.

thank you very much aao123.




Re: Visual C++ General Reserve Physical Memory

einaros

Rupesh Bhurke wrote:
Hi einaros !

Thank you for your suggestions but I've run out of options. I mean I have already tried
SetProcessWorkingSetSize but does not seem to work.

Anyways, I am trying for some other aproach. If it's successful I will post it here. Till then I'll keep thread open.

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

#define PROCMIN 100 * 1024 * 1024
#define PROCMAX 110 * 1024 * 1024
#define THESIZE PROCMIN

int main(int argc, char** argv)
{
SetProcessWorkingSetSize(GetCurrentProcess(), PROCMIN, PROCMAX);
void* mem = VirtualAlloc(NULL, THESIZE, MEM_COMMIT, PAGE_READWRITE);
VirtualLock(mem, THESIZE);
// ...
VirtualUnlock(mem, THESIZE);
VirtualFree(mem, THESIZE, MEM_RELEASE);
return 0;
}

Worked like a charm. However, you shouldn't do this, as aao123 points out.






Re: Visual C++ General Reserve Physical Memory

crescens2k

Here is my thoughts on this.

First of all, I doubt that MPEG2 muxing would require 100MB of contiguous physical memory to work correctly. All other muxers that I know of actually use the windows virtual memory system to operate and they work just fine.

Second, doing this would have a very bad effect on systems without much in the way of RAM. Take a system with just 256MB for example, after the paged and nonpaged pool have been allocated, the rest would go for the system. These pools will take a good chunk out of the available physical RAM. Then you want to allocate 100MB. You are then fighting the whole system for 100MB then you want to hold it to MUX and then finally release it. During the MUXing process then the system will be 100MB short and will run so badly that you will think that there is a huge problem with the system. On my system the kernel uses up 128MB of RAM, this won't be so much on systems with lower RAM, but it will still be a significant amount.

Third, you have the problem of allocating memory which is contiguous because of memory fragmentation. The VM system uses bits of it scattered throughout the RAM and you can't guarentee that there will be that amount free. VirtualAlloc requires contiguous memory otherwise it will fail. On systems with lower amounts of RAM this will be a huge problem and even on systems with larger amounts of RAM this can still cause problems if the computer has been on some time and has several working processes.

Finally, what you want to do can be done normally with the windows memory management system. To me it seems as if you don't understand how the windows memory management works. The biggest thing to remember is that windows never allows other processes to interfere with your memory, so you will have no problems just using the memory management features. Also if you want to keep your data in memory then there are other ways to do it, and more importantly, it will only be paged out when it hasn't been used for a while.

I think you should really think about what you are and want to do, and maybe learn a bit about how windows handles memory.






Re: Visual C++ General Reserve Physical Memory

Rupesh Bhurke

Hi einaros,

Thanks for the code. I have tried out something similar. But does it guarantee that the memory allocated this way will not be paged to pagefile

Best Regards,
Rupesh




Re: Visual C++ General Reserve Physical Memory

einaros

Rupesh Bhurke wrote:

Thanks for the code. I have tried out something similar. But does it guarantee that the memory allocated this way will not be paged to pagefile

Granted that the return value of VirtualLock is non-zero, the memory will (according to the documents I've read) be locked.






Re: Visual C++ General Reserve Physical Memory

Simple Samples

Rupesh Bhurke wrote:
I want to make sure that when my filter comes into memory it should have:

1. 100 MB of Physical Memory (non-pageable memory) or it can gracefully shutdown.
2. Once it has got hold of memory windows should not allocate that physical memory to any other application till my filter releases it.
If those are the reasons to force memory to not be paged then Windows will be unhappy. The reason for fixing pages in memory is so that external devices that write to memory will be able to do that when it needs to. There are other reasons but the situation is similar.

As best as I know, and my experience is not recent, Windows does not assure that memory locked by an application will remain locked. As best as I know, if you have a valid reason to use fixed pages then you should write a device driver or something like that.

I think that most of the other comments indicating that fixing pages in memory can result in a significant performance degradation for the other processes in the sytem are accurate.