Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Still confused why working set larger than virtual memory

90 views
Skip to first unread message

George

unread,
Jan 11, 2008, 9:39:01 AM1/11/08
to
Hello everyone,


Sorry that this question is related to another question I posted some time
before because I have some new findings and self-analysis.

My question is why sometimes from perfmon on Windows, working set larger
than virtual memory? I think virtual memory is the total size of memory
(committed, reserved, shared, private) and working set is just the RAM
touched by current process currently. Virtual memory should always larger
than working set...

But, I write a simple program to show working set is larger than virtual
memory from perfmon. The program is simple, just open a couple of memory map
files and read from beginning to the end.

The only reason I could think of why working set sometimes is larger than
virtual memory is, the OS memory management component may not reclaim some
RAM consumed by current process even if the current process does not use the
RAM. And keeping such RAM could improve performance if the process will use
it in the future. But this point makes me confused because I think if it is
true, such RAM does not have related virtual memory address, how could the
current process utilize or even address (re-use to avoid hard page fault) it
in the future?


thanks in advance,
George

Tom Walker

unread,
Jan 11, 2008, 11:21:57 AM1/11/08
to
"George" <Geo...@discussions.microsoft.com> wrote in message
news:6B8F857E-7C25-48A6...@microsoft.com...
> Hello everyone,

<snip>

George,
Are you aware that all of your posts to the microsoft.public.vc.language
newsgroup are being cross-posted to the
microsoft.public.win32.programmer.kernel newsgroup? Stop doing that.

Alexander Nickolov

unread,
Jan 11, 2008, 1:20:33 PM1/11/08
to
I don't see any evidence of cross-posting myself. Perhaps you
mean multiposted and are suggesting OP should use crossposting
instead?

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Tom Walker" <nob...@nowhere.com> wrote in message
news:uggsb4GV...@TK2MSFTNGP03.phx.gbl...

George

unread,
Jan 12, 2008, 9:56:00 AM1/12/08
to
Sorry, Tom!


I will post there. I am debugging my VC++ application and met with a memory
issue, so I come here as default. :-)


regards,
George

Ondrej Spanel

unread,
Jan 12, 2008, 10:12:16 AM1/12/08
to
> true, such RAM does not have related virtual memory address, how could the
> current process utilize or even address (re-use to avoid hard page fault) it
> in the future?

There is one special case with filemapping - you may have pages
allocated in a physical memory (be it RAM or page file), which have no
virtual address mapped. You can address such memory by creating a view
to it, use it, and then unmap again. To identify the location you use
the position in the file, and the memory is still committed even when
you do not have any virtual address mapped to it. Each time after you
map the view, you will get a soft page fault on first access, not the
hard one.

However, while this technique is definitely interesting, I never seen
such pages to be reported as a part of the working set (I am using
Process Explorer though, not PerfMon as you do).

(You might perhaps also find my reply to your older topic "File map
performance" of some interest)

Regards
Ondrej

George

unread,
Jan 13, 2008, 2:12:00 AM1/13/08
to
Thanks Ondrej,


Two more comments,

1.

Your described sample is interesting. Have you experienced any situations
when working set (counter in Perfmon) is larger than virtual memory (counter)?

2.

I think in your below case, you mentioned the file map pages are not counted
as part of the working set. How do you know that? Which tool/technique you
are using to check some specific page belongs to working set or not?


regards,
George

Ondrej Spanel

unread,
Jan 14, 2008, 3:39:37 AM1/14/08
to
> 1.
> Your described sample is interesting. Have you experienced any
situations
> when working set (counter in Perfmon) is larger than virtual memory
(counter)?

I do not know. I have no experience with PerfMon. I do not know if what
I wrote is really an answer to your question, however as it seems to be
related, I wrote it hoping it might help you in some way.

> 2.
> I think in your below case, you mentioned the file map pages are not
counted
> as part of the working set. How do you know that? Which
tool/technique you
> are using to check some specific page belongs to working set or not?

I know this because even when using very large mapped files this way,
the working set stays very low. I measure process working set size using
SysInternals Process Explorer or by default Windows Task Manager.
Moreover, in some applications I use GetProcessMemoryInfo from
PSAPI.DLL, which way I can get the same values as those tools do, but
programatically. The same tools also report the number of page faults,
however they do not distinguish between hard and soft ones. In case you
are interested, I attach my test source which I used for my file mapping
measurements. When running this source, I see following:

- the CPU load is 100 % of 1 CPU, which means no hard page faults (with
hard page faults the CPU would be idle while pages are loaded)
- I can see I page fault per 4 KB page access
- I can see very little memory reported as a working set
- I can see the page file space reserved on CreateFileMapping, and
physical memory being used after MapViewOfFile/UnmapViewOfFile, as
evidenced by GlobalMemoryStatus results

I suppose file pages which are currently mapped into a view are counted
as a part of both the working set and used virtual memory, however I did
not perform any experiments in this sense. This sample demonstrates how
to have physical memory allocated without using any virtual addresses
for it, by creating paging file backed file mapping and creating view
only as necessary.

Regards
Ondrej


Source follows:
-----------------------------------------
#include <windows.h>
#include <stdio.h>

int main(int argc, char* argv[])
{
LARGE_INTEGER start,end;
LARGE_INTEGER freq;
QueryPerformanceCounter(&start);
QueryPerformanceFrequency(&freq);

MEMORYSTATUS memstat;
memstat.dwLength = sizeof(memstat);
GlobalMemoryStatus(&memstat);

// basic file mapping test (512 MB)
long long size = 512*1024*1024;

HANDLE mapping =
CreateFileMapping(NULL,NULL,PAGE_READWRITE|SEC_COMMIT,(DWORD)(size>>32),DWORD(size),NULL);
if (mapping)
{
// create and destroy temporary views
SYSTEM_INFO sysInfo;
GetSystemInfo(&sysInfo);
const int allocSize = sysInfo.dwAllocationGranularity;

GlobalMemoryStatus(&memstat);

void *mem = new char[allocSize];
memset(mem,0x11,allocSize);
for (int i=0; i<10; i++)
{
for (long long offset=0; offset<=size-allocSize; offset+=allocSize)
{
void *map =
MapViewOfFile(mapping,FILE_MAP_WRITE,(DWORD)(offset>>32),(DWORD)offset,allocSize);
if (map)
{
memcpy(map,mem,allocSize);
UnmapViewOfFile(map);
}
}
GlobalMemoryStatus(&memstat);


for (long long offset=0; offset<=size-allocSize; offset+=allocSize)
{
void *map =
MapViewOfFile(mapping,FILE_MAP_READ,(DWORD)(offset>>32),(DWORD)offset,allocSize);
if (map)
{
for (int t=0; t<allocSize; t++)
{
if (((char *)map)[t]!=0x11)
{
OutputDebugString("Memory read failed\n");
}
}
UnmapViewOfFile(map);
}
}
GlobalMemoryStatus(&memstat);
}
QueryPerformanceCounter(&end);

GlobalMemoryStatus(&memstat);

printf("Time %.3f\n",
double(end.QuadPart-start.QuadPart)/double(freq.QuadPart));
CloseHandle(mapping);
delete[] mem;
GlobalMemoryStatus(&memstat);
}


return 0;
}
--------------------------------

George napsal(a):

George

unread,
Jan 15, 2008, 12:06:02 AM1/15/08
to
Thanks Ondrej,


Your sample is great! I am still studying it. Two more comments,

1.

> I know this because even when using very large mapped files this way,
> the working set stays very low. I measure process working set size using
> SysInternals Process Explorer or by default Windows Task Manager.

I am using Windows Server 2003. What OS are you using? In Windows Server
2003, there is no parameter called working set. How could you use Task
manager to monitor working set?

2.

> I suppose file pages which are currently mapped into a view are counted
> as a part of both the working set and used virtual memory, however I did
> not perform any experiments in this sense. This sample demonstrates how
> to have physical memory allocated without using any virtual addresses
> for it, by creating paging file backed file mapping and creating view
> only as necessary.

I do not agree that there is something which does not have virtual memory
address that you can access. In my knowledge (limited), everything we access
should have virtual address from process perspective. How do you know the
page map file does not have virtual address but in RAM when you access it?

George

unread,
Jan 15, 2008, 3:03:04 AM1/15/08
to
Hi Ondrej,


I have studied your sample code, and modify it to show my points. In your
test program, the working set is low because of each time after you use the
portion of the memory map file, you close it.

In my scenario, I keep it open. Here is my code based on your code and you
can see working set is much higher than virtual bytes, this is the situation
I described in my question. Any ideas?

(Here is my code, if there is anything wrong with my code, please also feel
free to let me know.)

#include <windows.h>
#include <stdio.h>

int main(int argc, char* argv[])
{
LARGE_INTEGER start,end;
LARGE_INTEGER freq;
QueryPerformanceCounter(&start);
QueryPerformanceFrequency(&freq);

MEMORYSTATUS memstat;
void* map;
memstat.dwLength = sizeof(memstat);
GlobalMemoryStatus(&memstat);

// basic file mapping test (512 MB)
long long size = 512*1024*1024;

HANDLE mapping =
CreateFileMapping(NULL,NULL,PAGE_READWRITE|SEC_COMMIT,(DWORD)(size>>32),DWORD(size),NULL);
if (mapping)
{
// create and destroy temporary views
SYSTEM_INFO sysInfo;
GetSystemInfo(&sysInfo);
const int allocSize = sysInfo.dwAllocationGranularity;

GlobalMemoryStatus(&memstat);

void *mem = new char[allocSize];
memset(mem,0x11,allocSize);
for (int i=0; i<10; i++)
{
for (long long offset=0; offset<=size-allocSize; offset+=allocSize)
{

map =
MapViewOfFile(mapping,FILE_MAP_WRITE,(DWORD)(offset>>32),(DWORD)offset,allocSize);
if (map)
{
memcpy(map,mem,allocSize);

// UnmapViewOfFile(map);
}
}

if (map)
{
UnmapViewOfFile(map);
}

GlobalMemoryStatus(&memstat);


for (long long offset=0; offset<=size-allocSize; offset+=allocSize)
{

map =
MapViewOfFile(mapping,FILE_MAP_READ,(DWORD)(offset>>32),(DWORD)offset,allocSize);
if (map)
{
for (int t=0; t<allocSize; t++)
{
if (((char *)map)[t]!=0x11)
{
OutputDebugString("Memory read failed\n");
}
}

// UnmapViewOfFile(map);
}
}
if (map)
{
UnmapViewOfFile(map);
}

GlobalMemoryStatus(&memstat);
} // for (int i=0; i<10; i++)

QueryPerformanceCounter(&end);

GlobalMemoryStatus(&memstat);

printf("Time %.3f\n",
double(end.QuadPart-start.QuadPart)/double(freq.QuadPart));
CloseHandle(mapping);
delete[] mem;
GlobalMemoryStatus(&memstat);

} //if (mapping)

return 0;

Alex Blekhman

unread,
Jan 15, 2008, 4:48:29 AM1/15/08
to
"George" wrote:
> I am using Windows Server 2003. What OS are you using? In
> Windows Server
> 2003, there is no parameter called working set. How could you
> use Task
> manager to monitor working set?

"Mem Usage" column is actually process working set size. See here
detailed description of Taks Manager columns:

"Overview of Performance Monitoring"
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/preb_mon_nbcl.mspx?mfr=true

See "Monitoring Processes" section.

Alex

Alex Blekhman

unread,
Jan 15, 2008, 4:49:22 AM1/15/08
to
"George" wrote:
> My question is why sometimes from perfmon on Windows, working
> set larger
> than virtual memory?

I think this article will help you to understand the issue:

"Myth: Without /3GB a single program can't allocate more than 2GB
of virtual memory"
http://blogs.msdn.com/oldnewthing/archive/2004/08/10/211890.aspx

Alex

George

unread,
Jan 15, 2008, 5:07:03 AM1/15/08
to
Hi Alex,


I have briefly read this article, you think my issue has something to do
woth /3GB option? Why? I do not think so. :-)


regards,
George

Ondrej Spanel

unread,
Jan 15, 2008, 7:13:28 AM1/15/08
to
> I am using Windows Server 2003. What OS are you using? In Windows Server

I am performing my tests on WinXP SP 2. With the SysInternals Process
Explorer the column is called Working Set. I guess with the task manager
some "user friendly" name is used (I tried to use PerfMon, however as I
am running Czech version of WinXP, I gave it up very seeon, because all
counter names are translated into Czech, and make no sense to me at all,
because they are translated in a very strange way)

> I have studied your sample code, and modify it to show my points. In
your
> test program, the working set is low because of each time after you
use the
> portion of the memory map file, you close it.

What you removed is exactly the "smart trick" to have memory
"accessible", but not "addressable". By using virtual addresses only
temporarily, you have the memory reserved to you, but you have no
permanent virtual addresses for it. Off course, using such memory is
limited - e.g. you cannot have any pointers pointing into such memory.
Approach like this is definitely necessary when you want to work with
huge mapped files (>> 1 GB), as they would not fit into the virtual
address space of the process.

> In my scenario, I keep it open. Here is my code based on your code
and you
> can see working set is much higher than virtual bytes, this is the
situation
> I described in my question. Any ideas?

My explanation for this would be the mapped portions of files are
counted as part of "working set", but not as "virtual bytes". However
without having exact definition or seeing the code OS uses to compute
the values, it is only a qualified guess, nothing more. The definition I
was able to find by short Googling "Shows the size, in bytes, of the
virtual address space that the process is using." does not tell much.
The results might also be OS dependent. When I tried it on my computer,
I have always seen "Virtual Size" higher then "Working Set".

> (Here is my code, if there is anything wrong with my code, please
also feel
> free to let me know.)

Your code leaks virtual address, as you map views you never unmap. While
for purposes of demonstrating the "working set is much higher than
virtual bytes" it probably does not matter, you would definitely not
want to do it like this in a production code. Each view you map needs to
be unmapped at well at some point. Even in this experiment this leak
causes virtual space exhausted once you reach ~2 GB of mapped views,
with all MapViewOfFile calls failing since that point.

Regards
Ondrej

George napsal(a):

Alexander Nickolov

unread,
Jan 15, 2008, 7:33:03 PM1/15/08
to
What pertains to your question is the fact you may have mapped,
used and unmapped many views. The pages you used in those views
would be in your working set, but they will not use virtual addresses.
In that case your working set may become larger than your virtual
memory address space. I think that's what everybody else was
trying to tell you so far.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"George" <Geo...@discussions.microsoft.com> wrote in message
news:0E724510-7EA1-40A3...@microsoft.com...

Ondrej Spanel

unread,
Jan 16, 2008, 3:50:16 PM1/16/08
to
Alexander Nickolov napsal(a):

> What pertains to your question is the fact you may have mapped,
> used and unmapped many views. The pages you used in those views
> would be in your working set, but they will not use virtual addresses.
> In that case your working set may become larger than your virtual
> memory address space. I think that's what everybody else was
> trying to tell you so far.
>

I would definitely agree with you in theory, however I am afraid it is
not that easy to demonstrate it in practice.

What you write definitely makes sense with the "encyclopaedia"
definition of the working set, however it is not what I see with Process
Explorer on WinXP SP 2. (I do not know what George sees on Win 2003
Server, perhaps he can see it there). In my code attached in this thread
what I see is even when I mapped and unmapped 512 MB of files, using 512
MB of physical memory and using no virtual addresses, I cannot see any
significant working set - the working set reported by both
GetProcessMemoryInfo and Process Explorer (which most likely uses
GetProcessMemoryInfo as well) stays only a few MB. I would expect those
pages to be counted as a part of the working set, exactly from the
reasons you outlines here, however this is not what I see. (As for why I
am sure the data stay in physical memory, see my other replies in this
thread)

I guess the best way to explain this would be to know the exact OS
definition of the "working set" value reported by GetProcessMemoryInfo.
The docs say "Current working set size, in bytes.", which really does
not reveal much.

(By the way, the pages mapped are also not counted in the PagefileUsage
member of the PROCESS_MEMORY_COUNTERS, which I also find unexpected,
because I create the file mapping object backed by the paging file).

Regards
Ondrej

George

unread,
Jan 17, 2008, 1:54:00 AM1/17/08
to
Hi Alexander,


I do not know why you mentioned in my case, there are pages belongs to the
working set of a process, but not have virtual address or belong to virtual
memory of a process. Could you provide more information please?


regards,
George

George

unread,
Jan 17, 2008, 1:53:00 AM1/17/08
to
Thanks Ondrej,


I have modified my program to show even if there is no leak, the working set
could be larger than vritual bytes. Could you help to double check please? :-)

If you have any ideas why in my application working set is larger than
virtual bytes, or if there is anything wrong, please feel free to let me know.

Some comments, In my program, I use two ways to hold file map.

1. keep all file map open and close all open handles altogether at the end;
2. close open handle each time after using it.

In (1), working set is much larger than virtual bytes, and in (2).

Here is my code.

#include <windows.h>
#include <stdio.h>

int main(int argc, char* argv[])
{
LARGE_INTEGER start,end;
LARGE_INTEGER freq;
QueryPerformanceCounter(&start);
QueryPerformanceFrequency(&freq);

MEMORYSTATUS memstat;
void** map;
int sectionIndex = 0;
memstat.dwLength = sizeof(memstat);
GlobalMemoryStatus(&memstat);

// basic file mapping test (512 MB)
long long size = 512*1024*1024;

HANDLE mapping =
CreateFileMapping(NULL,NULL,PAGE_READWRITE|SEC_COMMIT,(DWORD)(size>>32),DWORD(size),NULL);
if (mapping)
{
// create and destroy temporary views
SYSTEM_INFO sysInfo;
GetSystemInfo(&sysInfo);
const int allocSize = sysInfo.dwAllocationGranularity;

GlobalMemoryStatus(&memstat);

void *mem = new char[allocSize];
memset(mem,0x11,allocSize);

map = (void**) new char [sizeof(void*) * size / allocSize];

for (int i=0; i<10; i++)
{

sectionIndex = 0;


for (long long offset=0; offset<=size-allocSize; offset+=allocSize)
{

map [sectionIndex] =
MapViewOfFile(mapping,FILE_MAP_WRITE,(DWORD)(offset>>32),(DWORD)offset,allocSize);
if (map [sectionIndex])
{
memcpy(map [sectionIndex],mem,allocSize);
// UnmapViewOfFile(map);
}

sectionIndex++;
} // for (long long offset=0; offset<=size-allocSize; offset+=allocSize)

// close mapped files to avoid leak
for (sectionIndex = 0; sectionIndex < size/allocSize; sectionIndex++)
{
if (map [sectionIndex])
{
UnmapViewOfFile(map [sectionIndex]);
}
}

GlobalMemoryStatus(&memstat);

sectionIndex = 0;


for (long long offset=0; offset<=size-allocSize; offset+=allocSize)
{

map [sectionIndex] =
MapViewOfFile(mapping,FILE_MAP_READ,(DWORD)(offset>>32),(DWORD)offset,allocSize);
if (map [sectionIndex])

{
for (int t=0; t<allocSize; t++)
{

if (((char *)(map [sectionIndex]))[t]!=0x11)

{
OutputDebugString("Memory read failed\n");
}
}
}

UnmapViewOfFile(map [sectionIndex]);
}

// close mapped files to avoid leak
/*
for (sectionIndex = 0; sectionIndex < size/allocSize; sectionIndex++)
{
if (map [sectionIndex])
{
UnmapViewOfFile(map [sectionIndex]);
}
}
*/

George

unread,
Jan 17, 2008, 2:09:00 AM1/17/08
to
Hi Ondrej,


Two more comments,


1.

> Server, perhaps he can see it there). In my code attached in this thread

> what I see is even when I mapped and unmapped 512 MB of files, using 512
> MB of physical memory and using no virtual addresses,

I still do not know how could the mapped file pages do not have virtual
address, but have physical address? In my mind, everything we can access in
current process should be in current process's address space. Could you
provide more information please?

2.

> MB of physical memory and using no virtual addresses, I cannot see any
> significant working set - the working set reported by both

You can not see any significant working set because you free the memory at
once when you complete using it. So, it is too fast and counter can not "see"
it. :-)

You can see my program (new version) posted above to see if we hold all
memory for a while and close all handles altogether at the end, you can find
the working set is much larger.

Any comments?


regards,
George

Ondrej Spanel

unread,
Jan 17, 2008, 5:30:55 AM1/17/08
to
George napsal(a):

>> Server, perhaps he can see it there). In my code attached in this thread
>> what I see is even when I mapped and unmapped 512 MB of files, using 512
>> MB of physical memory and using no virtual addresses,
>
> I still do not know how could the mapped file pages do not have virtual
> address, but have physical address? In my mind, everything we can access in
> current process should be in current process's address space. Could you
> provide more information please?

I will answer for the last time, however I think you should be able to
see this for yourself already, as all information is in the sample.

I can map the page, will it with data, and unmap it. The next time I map
the same part of the file, it still contains the same data I filled it
before, demonstrating it resided somewhere (I also explained why I am
sure they resided in the physical memory, not in the page file). Off
course, each time you want to access the data, it needs to have a
virtual address, but the trick is it does not need to have any permanent
virtual address, and it is able to exist even without a virtual address,
as it exists as a part of the file mapping (as for whether it has a
physical address meanwhile, it is not that interesting - it probably has
while it resides in the physical memory, in case it is swapped out, it
does not have it any more, but this is not something I need to care
about, OS takes care of this).

This also exactly what Alexander Nickolov is talking about: even when
you unmap your file views, the pages still may reside in the memory and
may be a part of the working set (the working set is a set of pages
recently used - it may contain even pages which do not have any virtual
address mapped right now, and this is useful because on mapping them
again you get only soft fault, not a hard one).

>> MB of physical memory and using no virtual addresses, I cannot see any
>> significant working set - the working set reported by both
>
> You can not see any significant working set because you free the memory at
> once when you complete using it. So, it is too fast and counter can not "see"
> it. :-)

I am not freeing the memory, I am only unmapping its virtual addresses.
The memory is "allocated" (committed) using CreateFileMapping and not
released until I release the mapping.

> You can see my program (new version) posted above to see if we hold all
> memory for a while and close all handles altogether at the end, you can find
> the working set is much larger.

No, I am sorry, this is not what I see with WinXP SP 2. Perhaps your OS
is counting workins set size in a different (more logical) way.

What I see is:

- while I am mapping more and more memory, both Virtual Size and Working
Set grow, Virtual Size keeping a little bit higher than Working Set
- once I unmap the memory, both Virtual Size and Working Set size go
down, Virtual Size still keeping a little bit higher than Working Set

If you see a working set in this situation to stay above 512 MB, it is
perfectly logical, as explained above, and it means the numbers your OS
is reporting are more reliable then mine.

Regards
Ondrej

George

unread,
Jan 17, 2008, 8:32:01 AM1/17/08
to
Thanks Ondrej,


Two more comments,

1.

I think you guys points are, each time we map the section of the file, it
has virtual address, and when we unmap it, it does not have virtual memory
address, but it resides in memory. This is what you mean it has physical
address, but does not have virtual address, right?

My question is how (from what fact) do you think it does not have virtual
memory address when we unmap it?

2.

I think you guys mean when we unmap some pages, since they are still in the
physical memory and counts as a part of the working set of current process
and at the same time they do not have virtual address, so we can see working
set is larger than virtual bytes.

It is not true even for my Windows Server 2003. If you read my post
carefully, :-), you can find on my Server system, when I unmap it, the
working set shirnks to very little value.

Please feel free to correct me if I am wrong.

Ondrej Spanel

unread,
Jan 19, 2008, 8:48:37 AM1/19/08
to
> physical memory and counts as a part of the working set of current
process
> and at the same time they do not have virtual address, so we can see
working
> set is larger than virtual bytes.

I do not know what definition of working set which OS uses when
reporting this value. Without knowing this, I cannot tell what values I
expect to be reported. On WinXP SP2 I never seen working set higher than
virtual bytes, even with your modified example.

> My question is how (from what fact) do you think it does not have
virtual
> memory address when we unmap it?

Because this is what mapping a view is: by mapping you are mapping
virtual addresses, and by unmaping you are releasing them again. If you
want to prove this, you should be able to construct a simple code using
VirtualQuery or VirtualAlloc, or by monitoring the global virtual space
usage using GlobalMemoryStatus (which mu code does) - and no, I have no
intention to construct such code for you.

Regards
Ondrej

George napsal(a):

George

unread,
Jan 19, 2008, 9:10:00 AM1/19/08
to
Thanks Ondrej,


I have some further study and experiment of my code and I want to share with
you and let you review whether you agree or have any comments?

Here is my further study,

[Code]


map [sectionIndex] =
MapViewOfFile(mapping,FILE_MAP_WRITE,(DWORD)(offset>>32),(DWORD)offset,allocSize);
if (map [sectionIndex])
{
memcpy(map [sectionIndex],mem,allocSize);
// UnmapViewOfFile(map);
}

[/Code]

I have studied your reply and my code again. I think may be it is cause of I
reused the buffer of variable map (it is 65535 bytes in my system), and only
this variable map buffer is counted as virtual address and the real memory
map file itself is not mapped into process virtual space with committed
pages, so the memory map file is not counted as part of the virtual address?
But since file map file RAM is *touched* by current process, it is counted by
working set of current process. Is that correct understanding?

And the variable map buffer is what you called adressable and accessible,
the page map file is what you called accessible (not direct accessing, but
through variable map buffer), but not addressable unless we use variable map
buffer to address it.

Agree with me or anything wrong with my reply?

Tom Widmer [VC++ MVP]

unread,
Jan 22, 2008, 9:49:32 AM1/22/08
to
George wrote:

> You can not see any significant working set because you free the memory at
> once when you complete using it. So, it is too fast and counter can not "see"
> it. :-)
>
> You can see my program (new version) posted above to see if we hold all
> memory for a while and close all handles altogether at the end, you can find
> the working set is much larger.
>
> Any comments?

Let's see some hard numbers: what is the exact bytes you are seeing for
the working set, and for virtual memory? You will find that the virtual
memory is actually much greater that the working set, even if the line
is lower on the perfmon window (which is a simple scaling issue).

Tom

0 new messages