Hi There,

I have an application that uses quite a bit of memory to maintain a 
database. This is a real-time, latency-sensitive app that needs this memory. 
Let's take that as a caveate and not suggest "use less memory". My machine 
has 16 gig of memory - I only want about 5 gig of that - a pittance, really. 
;) I'm running on 64-bit XP using dev studio 2005 verstion 8.0.50727.42 
(RTM.050727-4200).

The application uses three shared memory regions. Two of them are one gig in 
size. One of them is 3 gig in size. I have enlarged my working set to about 6 
gig to encompass the shared regions, my program code, a few internal structs 
and the like. Upon startup, the app begins to "allocate" buffers from the 3 
gig region while processing transactions from a ring buffer (one of the one 
gig regions). The "main database" lies in the other one gig region and is 
accessed randomly as transactions fly in. At first the app runs very smoothly 
and quickly. It pages in about 2 gig very quickly and runs for about a half 
hour very well. Once the 3 gig buffer region begins to be consumed (once it's 
about 80% used) the app slows to a crawl.

Using process explorer, and several of my own breadcrumbs, I find that I am 
"stuck" accessing a pointer most of the time (a pointer into the 3 gig 
region). The 3 gig region, by the way, is mapped into the "highest" address 
space - I hope that makes sense. Process explorer shows this as my stack:

ntoskrnl.exe!ExAcquireSharedWaitForExclusive+0x115
ntoskrnl.exe!ExAcquireSharedWaitForExclusive+0x545
ntoskrnl.exe!MmProbeAndLockPages+0x5ce
ntoskrnl.exe!KeSynchronizeExecution+0x41c
ntoskrnl.exe!ExfReleasePushLock+0x1f
ntoskrnl.exe!ObReferenceObjectByPointer+0x16d
ntoskrnl.exe!LsaFreeReturnBuffer+0x2913
ntoskrnl.exe!IoFreeController+0x547
ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x82f
ntoskrnl.exe!NtAllocateVirtualMemory+0x4b7
timeseries.EXE+0x5c200

This looks to me to be memory management stuff. I'm mildly disturbed by the 
"allocateVirtualMemory" entry point because I'm NOT allocating virtual memory 
- I'm accessing a pointer of a mapped shared region.

Process explorer suffers mightily while trying to examine my process. It 
frequently sits there for quite a long time before it actual does anything.

I have tried using Virtuallock to hold the pages in my working set to 
improve performance, but alas, this does not help. The virtuallock call takes 
MINUTES to complete and the performance is still swirling deeply in the 
toilet.

I have a small service that creates the shared region and "holds it" in 
memory as I stop and start this program and one other that map these regions 
to examine the current data and store new data.

Questions:

Since this is shared memory, SHOULD I be locking it in my working set? If 
so, why does the performance still stink?

What can I do to improve the memory access of this very large shared region? 
Increase my working set more?

Process explorer only seems to suffer when my app is also suffering.. could 
my system simply need some tuning? If so, what do I tweak to make this 
machine better use it's honking 16 gig of RAM?

--- More info ---

It did NOT seem to help to have the original creator of the region (the 
little  service I mentioned before that "holds open" the shared memory) lock 
the pages down. On the contrary, this resulted in my processes totally 
locking up. I couldn't kill it with taskmanager or process explorer. I had to 
reboot.

I NEED this to work...it SHOULD work. It just doesn't and I don't know why. 
Please help me to understand. I have programmed on VMS systems and this 
shared memory stuff - the non-paged pool references etc. look very VMS-like. 
No surprise really since it was probably designed by the illustrius David 
Cutler, the father of VMS. If there is some way to reserve this memory and 
keep it "as my own" - that is, keep XP from paging it or charging my process 
for it or whatever, please tell me.

Thanks for your time.

I'm going to plead complete ignorance here, and ask a few very basic 
questions:

What is shared memory? To me, shared memory means a memory mapped file, or 
something similar. Based on the context you're using it in, it doesn't sound 
like you're talking about a Memory Mapped file.

What language are developing in? Are you in Native C++ / MFC, Managed / 
Mixed C++, or C#?

Some basic thoughts, just based on your call-stack:
- Allocations in whatever technology you're using look to require exclusive 
ownership of a Mutex of some sort. If you've got multiple processes / 
threads reading & writing to this area, you're going to need to do some 
smarter memory management. Pre-allocate large pools of objects, and such.

A classic (and silly) trick: Turn your page file size waaay down. Try "0". 
That way nothing is paged out.

-- 
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"GregP"  wrote in message 
news:F99ACAD2-61FE-46DB-B34C-66B9A9D585DC@microsoft.com...

> Hi There,
>
> I have an application that uses quite a bit of memory to maintain a
> database. This is a real-time, latency-sensitive app that needs this 
> memory.
> Let's take that as a caveate and not suggest "use less memory". My machine
> has 16 gig of memory - I only want about 5 gig of that - a pittance, 
> really.
> ;) I'm running on 64-bit XP using dev studio 2005 verstion 8.0.50727.42
> (RTM.050727-4200).
>
> The application uses three shared memory regions. Two of them are one gig 
> in
> size. One of them is 3 gig in size. I have enlarged my working set to 
> about 6
> gig to encompass the shared regions, my program code, a few internal 
> structs
> and the like. Upon startup, the app begins to "allocate" buffers from the 
> 3
> gig region while processing transactions from a ring buffer (one of the 
> one
> gig regions). The "main database" lies in the other one gig region and is
> accessed randomly as transactions fly in. At first the app runs very 
> smoothly
> and quickly. It pages in about 2 gig very quickly and runs for about a 
> half
> hour very well. Once the 3 gig buffer region begins to be consumed (once 
> it's
> about 80% used) the app slows to a crawl.
>
> Using process explorer, and several of my own breadcrumbs, I find that I 
> am
> "stuck" accessing a pointer most of the time (a pointer into the 3 gig
> region). The 3 gig region, by the way, is mapped into the "highest" 
> address
> space - I hope that makes sense. Process explorer shows this as my stack:
>
> ntoskrnl.exe!ExAcquireSharedWaitForExclusive+0x115
> ntoskrnl.exe!ExAcquireSharedWaitForExclusive+0x545
> ntoskrnl.exe!MmProbeAndLockPages+0x5ce
> ntoskrnl.exe!KeSynchronizeExecution+0x41c
> ntoskrnl.exe!ExfReleasePushLock+0x1f
> ntoskrnl.exe!ObReferenceObjectByPointer+0x16d
> ntoskrnl.exe!LsaFreeReturnBuffer+0x2913
> ntoskrnl.exe!IoFreeController+0x547
> ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x82f
> ntoskrnl.exe!NtAllocateVirtualMemory+0x4b7
> timeseries.EXE+0x5c200
>
> This looks to me to be memory management stuff. I'm mildly disturbed by 
> the
> "allocateVirtualMemory" entry point because I'm NOT allocating virtual 
> memory
> - I'm accessing a pointer of a mapped shared region.
>
> Process explorer suffers mightily while trying to examine my process. It
> frequently sits there for quite a long time before it actual does 
> anything.
>
> I have tried using Virtuallock to hold the pages in my working set to
> improve performance, but alas, this does not help. The virtuallock call 
> takes
> MINUTES to complete and the performance is still swirling deeply in the
> toilet.
>
> I have a small service that creates the shared region and "holds it" in
> memory as I stop and start this program and one other that map these 
> regions
> to examine the current data and store new data.
>
> Questions:
>
> Since this is shared memory, SHOULD I be locking it in my working set? If
> so, why does the performance still stink?
>
> What can I do to improve the memory access of this very large shared 
> region?
> Increase my working set more?
>
> Process explorer only seems to suffer when my app is also suffering.. 
> could
> my system simply need some tuning? If so, what do I tweak to make this
> machine better use it's honking 16 gig of RAM?
>
> --- More info ---
>
> It did NOT seem to help to have the original creator of the region (the
> little  service I mentioned before that "holds open" the shared memory) 
> lock
> the pages down. On the contrary, this resulted in my processes totally
> locking up. I couldn't kill it with taskmanager or process explorer. I had 
> to
> reboot.
>
> I NEED this to work...it SHOULD work. It just doesn't and I don't know 
> why.
> Please help me to understand. I have programmed on VMS systems and this
> shared memory stuff - the non-paged pool references etc. look very 
> VMS-like.
> No surprise really since it was probably designed by the illustrius David
> Cutler, the father of VMS. If there is some way to reserve this memory and
> keep it "as my own" - that is, keep XP from paging it or charging my 
> process
> for it or whatever, please tell me.
>
> Thanks for your time. 

> I'm going to plead complete ignorance here, and ask a few very basic 
> questions:
>
> What is shared memory? To me, shared memory means a memory mapped file, or 
> something similar. Based on the context you're using it in, it doesn't 
> sound like you're talking about a Memory Mapped file.
>
> What language are developing in? Are you in Native C++ / MFC, Managed / 
> Mixed C++, or C#?
>
> Some basic thoughts, just based on your call-stack:
> - Allocations in whatever technology you're using look to require 
> exclusive ownership of a Mutex of some sort. If you've got multiple 
> processes / threads reading & writing to this area, you're going to need 
> to do some smarter memory management. Pre-allocate large pools of objects, 
> and such.
>
> A classic (and silly) trick: Turn your page file size waaay down. Try "0". 
> That way nothing is paged out.


All good ideas to try.

I would add the following:
1) Post this to http://www.osronline.com/

2) And to microsoft.public.win32.programmer.kernel

3) Is your problem related to data locality?  Are you hammering your cpu 
cache?
You might try another box with more cache, perhaps one of the 16mb xeons..

4) Where is your data coming from?  if from disk then be sure that windows
is not caching the files.  Sounds like you only need to touch each
item one time.  Windows has a bad habit of caching things that need not be.
ie. copy a several gig file, and almost the entire OS is paged out.  Windows 
reports
this memory as available, but keeps the cache anyway, and resurects stuff as 
needed.
Check here for some utils:  http://www.uwe-sieber.de/ntcacheset_e.html

5) Your stack trace is many levels below .Net.  If you are fighting the 
design decisions
made in the kernel you will not have much fun..

6) Why shared memory at all?  You seem to have a classic client/server 
architecture
with a db, and an app to process it.  Ask the DB for a copy of the data, do 
some
stuff to it, then return it to the db.  No sharing.

7) How many cpu's?  They must maintain cache coherence.  There will be 
overhead here.
Even if you are doing all the memory locking correctly, and everything is 
synchronized
in your code, there still could be a lot of cpu cache coherence stuff 
bogging things down.
Perhaps a visit to a hardware vendor would be worth the time.  IE if you 
have a xeon box
try an AMD one.  Very different FSB's and cache coherence overheads.

8)  Instrument your code.  I wrote a helper class in about 6 hours called 
PerfMon2Pic.
It sets up a timer, grabs perfmon samples, and plots them in a bitmap.  I 
added a method
to write text  vertically in the pic at the current X position.  Then I 
increment the X
by the width of the text.  So you get the values on the y axis, and the X is 
time.
with gaps in the x containing comments.  Sprinkle some calls in your code to 
call
this at checkpoints in your prog.  In my app I was hammered by disk.  So I 
had nice plots
with Avail Mem, Disk Queue length, File Cache size, etc.

With these pictures it is easy to see when your app starts going wrong. 
Change some code
then do it again.  Compare the pictures, etc.

Find your hotspots, and tune them. Rinse/repeat.

Good luck!

Hi Chris,

I'm afraid it is I who should claim ignorance. I'm using terminology that 
I've carried with me for years and need to keep myself focused on the OS that 
I'm dealing with at this time.

Yes, shared memory is a memory-mapped file. For whatever reason, MS felt the 
need to call it that. Though, using it with the system paging file, it feels 
wrong to call it a memory mapped file. Be that as it may, that's what it's 
called on Windows. Sorry to have been obtuse.

I'm using Visual Studio and MS C++.

As for allocations, well, I'm not allocating anything. I'm accessing this 
section of memory (the memory mapped file). I suspect the 
Allocatevirtualmemory that is shown in my stack trace is basically "Allocate 
non-paged pool", which translates to "I need physical memory". It's not your 
classic "malloc" or "new" or something like that.

I like the idea of shrinking the page file to nothing or almost nothing. I 
think I'll give it a go.

Thanks for your help!

"Chris Mullins [MVP]" wrote:


> I'm going to plead complete ignorance here, and ask a few very basic 
> questions:
> 
> What is shared memory? To me, shared memory means a memory mapped file, or 
> something similar. Based on the context you're using it in, it doesn't sound 
> like you're talking about a Memory Mapped file.
> 
> What language are developing in? Are you in Native C++ / MFC, Managed / 
> Mixed C++, or C#?
> 
> Some basic thoughts, just based on your call-stack:
> - Allocations in whatever technology you're using look to require exclusive 
> ownership of a Mutex of some sort. If you've got multiple processes / 
> threads reading & writing to this area, you're going to need to do some 
> smarter memory management. Pre-allocate large pools of objects, and such.
> 
> A classic (and silly) trick: Turn your page file size waaay down. Try "0". 
> That way nothing is paged out.
> 
> -- 
> Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
> http://www.coversant.com/blogs/cmullins
> 
> "GregP"  wrote in message 
> news:F99ACAD2-61FE-46DB-B34C-66B9A9D585DC@microsoft.com...
> > Hi There,
> >
> > I have an application that uses quite a bit of memory to maintain a
> > database. This is a real-time, latency-sensitive app that needs this 
> > memory.
> > Let's take that as a caveate and not suggest "use less memory". My machine
> > has 16 gig of memory - I only want about 5 gig of that - a pittance, 
> > really.
> > ;) I'm running on 64-bit XP using dev studio 2005 verstion 8.0.50727.42
> > (RTM.050727-4200).
> >
> > The application uses three shared memory regions. Two of them are one gig 
> > in
> > size. One of them is 3 gig in size. I have enlarged my working set to 
> > about 6
> > gig to encompass the shared regions, my program code, a few internal 
> > structs
> > and the like. Upon startup, the app begins to "allocate" buffers from the 
> > 3
> > gig region while processing transactions from a ring buffer (one of the 
> > one
> > gig regions). The "main database" lies in the other one gig region and is
> > accessed randomly as transactions fly in. At first the app runs very 
> > smoothly
> > and quickly. It pages in about 2 gig very quickly and runs for about a 
> > half
> > hour very well. Once the 3 gig buffer region begins to be consumed (once 
> > it's
> > about 80% used) the app slows to a crawl.
> >
> > Using process explorer, and several of my own breadcrumbs, I find that I 
> > am
> > "stuck" accessing a pointer most of the time (a pointer into the 3 gig
> > region). The 3 gig region, by the way, is mapped into the "highest" 
> > address
> > space - I hope that makes sense. Process explorer shows this as my stack:
> >
> > ntoskrnl.exe!ExAcquireSharedWaitForExclusive+0x115
> > ntoskrnl.exe!ExAcquireSharedWaitForExclusive+0x545
> > ntoskrnl.exe!MmProbeAndLockPages+0x5ce
> > ntoskrnl.exe!KeSynchronizeExecution+0x41c
> > ntoskrnl.exe!ExfReleasePushLock+0x1f
> > ntoskrnl.exe!ObReferenceObjectByPointer+0x16d
> > ntoskrnl.exe!LsaFreeReturnBuffer+0x2913
> > ntoskrnl.exe!IoFreeController+0x547
> > ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x82f
> > ntoskrnl.exe!NtAllocateVirtualMemory+0x4b7
> > timeseries.EXE+0x5c200
> >
> > This looks to me to be memory management stuff. I'm mildly disturbed by 
> > the
> > "allocateVirtualMemory" entry point because I'm NOT allocating virtual 
> > memory
> > - I'm accessing a pointer of a mapped shared region.
> >
> > Process explorer suffers mightily while trying to examine my process. It
> > frequently sits there for quite a long time before it actual does 
> > anything.
> >
> > I have tried using Virtuallock to hold the pages in my working set to
> > improve performance, but alas, this does not help. The virtuallock call 
> > takes
> > MINUTES to complete and the performance is still swirling deeply in the
> > toilet.
> >
> > I have a small service that creates the shared region and "holds it" in
> > memory as I stop and start this program and one other that map these 
> > regions
> > to examine the current data and store new data.
> >
> > Questions:
> >
> > Since this is shared memory, SHOULD I be locking it in my working set? If
> > so, why does the performance still stink?
> >
> > What can I do to improve the memory access of this very large shared 
> > region?
> > Increase my working set more?
> >
> > Process explorer only seems to suffer when my app is also suffering.. 
> > could
> > my system simply need some tuning? If so, what do I tweak to make this
> > machine better use it's honking 16 gig of RAM?
> >
> > --- More info ---
> >
> > It did NOT seem to help to have the original creator of the region (the
> > little  service I mentioned before that "holds open" the shared memory) 
> > lock
> > the pages down. On the contrary, this resulted in my processes totally
> > locking up. I couldn't kill it with taskmanager or process explorer. I had 
> > to
> > reboot.
> >
> > I NEED this to work...it SHOULD work. It just doesn't and I don't know 
> > why.
> > Please help me to understand. I have programmed on VMS systems and this
> > shared memory stuff - the non-paged pool references etc. look very 
> > VMS-like.
> > No surprise really since it was probably designed by the illustrius David
> > Cutler, the father of VMS. If there is some way to reserve this memory and
> > keep it "as my own" - that is, keep XP from paging it or charging my 
> > process
> > for it or whatever, please tell me.
> >
> > Thanks for your time. 
> 
> 
> 

Hello Robert,

Thank you very much for the suggestions for additional posts. I will 
certainly do that. 

re: 3) This is an AMD box. It's possible data locality is an issue, but IMHO 
getting the cpu caches coherent could not possibly be causing this drastic of 
a slow-down. It feels as though only disk I/O (IE paging) could cause this. 
The application is literally frozen for seconds (and much longer) until I 
either break into it with the debugger or it somehow finishes it's paging.

re: 4) My data is coming in via network packets so the disk file caching 
shouldn't be an issue.

re: 5) Indeed, I'm down in the bowels of the kernel. I certainly don't want 
to fight it, I want to understand it and use it correctly. There's something 
here that I don't understand fully and I'm probably making some assumption 
that is false.

re: 6) There are many advantages to using shared memory. For one, this 
database needs to be persistent. A simple re-start of the program would cause 
long periods of recovery as it read it's "last known good state" from some 
recover file or files. Ick. As it stands, re-starts are virtually 
instantaneous.
Shared memory also allows quite a bit of visibility into the data by 
utilities and "consumer" applications. While copying could (and does ) work I 
can't spare the cycles for it at 2 million (and increasing) transactions per 
second. I also tend to doubt that the fact that this memory is shared is 
causing me any real grief. I suspect that if I was using memory sections of 
this size "locally" my paging problems (or whatever this is) would still be 
evident.

re: 7) I have 8 CPUs. I am going to experiment with affinitizing the 
producer and consumer to specific (possibly the same) cpu to see if this 
alleviates the problem. There are also various reasons that we are locked 
into AMD. So trying a Xeon isn't really possible for me at this time.

re: 8) I do have similar benchmarking utilities/code. Another benefit of 
shared memory is that you can set markers into statistics areas to see where 
you are, what you are doing, how many transactions have been processed, etc. 
This very thing was what allowed me to see that I was not in the middle of an 
I/O (not an I/O issed by me) when I locked up.  On the contrary, I was in the 
middle of updating a transaction in memory - accessing a pointer. This is the 
puzzling (and frustrating) thing. To be sure I could very well have been 
faulting in (or out) large swaths of memory. Task manager showed that I was 
page faulting occasionally but when I froze the faulting ceased. It's very 
strange. Hopefully some of the kernal gurus may be able to tell me what could 
be going on.

Thank you very much for all your help!

Greg


> All good ideas to try.
> 
> I would add the following:
> 1) Post this to http://www.osronline.com/
> 
> 2) And to microsoft.public.win32.programmer.kernel
> 
> 3) Is your problem related to data locality?  Are you hammering your cpu 
> cache?
> You might try another box with more cache, perhaps one of the 16mb xeons..
> 
> 4) Where is your data coming from?  if from disk then be sure that windows
> is not caching the files.  Sounds like you only need to touch each
> item one time.  Windows has a bad habit of caching things that need not be.
> ie. copy a several gig file, and almost the entire OS is paged out.  Windows 
> reports
> this memory as available, but keeps the cache anyway, and resurects stuff as 
> needed.
> Check here for some utils:  http://www.uwe-sieber.de/ntcacheset_e.html
> 
> 5) Your stack trace is many levels below .Net.  If you are fighting the 
> design decisions
> made in the kernel you will not have much fun..
> 
> 6) Why shared memory at all?  You seem to have a classic client/server 
> architecture
> with a db, and an app to process it.  Ask the DB for a copy of the data, do 
> some
> stuff to it, then return it to the db.  No sharing.
> 
> 7) How many cpu's?  They must maintain cache coherence.  There will be 
> overhead here.
> Even if you are doing all the memory locking correctly, and everything is 
> synchronized
> in your code, there still could be a lot of cpu cache coherence stuff 
> bogging things down.
> Perhaps a visit to a hardware vendor would be worth the time.  IE if you 
> have a xeon box
> try an AMD one.  Very different FSB's and cache coherence overheads.
> 
> 8)  Instrument your code.  I wrote a helper class in about 6 hours called 
> PerfMon2Pic.
> It sets up a timer, grabs perfmon samples, and plots them in a bitmap.  I 
> added a method
> to write text  vertically in the pic at the current X position.  Then I 
> increment the X
> by the width of the text.  So you get the values on the y axis, and the X is 
> time.
> with gaps in the x containing comments.  Sprinkle some calls in your code to 
> call
> this at checkpoints in your prog.  In my app I was hammered by disk.  So I 
> had nice plots
> with Avail Mem, Disk Queue length, File Cache size, etc.
> 
> With these pictures it is easy to see when your app starts going wrong. 
> Change some code
> then do it again.  Compare the pictures, etc.
> 
> Find your hotspots, and tune them. Rinse/repeat.
> 
> Good luck! 
> 
> 
> 

> Thank you very much for the suggestions for additional posts. I will
> certainly do that.
>
> re: 3) This is an AMD box. It's possible data locality is an issue, but IMHO
> getting the cpu caches coherent could not possibly be causing this drastic of
> a slow-down. It feels as though only disk I/O (IE paging) could cause this.
> The application is literally frozen for seconds (and much longer) until I
> either break into it with the debugger or it somehow finishes it's paging.


True, this should be milliseconds, not seconds or minutes..


> re: 4) My data is coming in via network packets so the disk file caching
> shouldn't be an issue.
>
> re: 5) Indeed, I'm down in the bowels of the kernel. I certainly don't want
> to fight it, I want to understand it and use it correctly. There's something
> here that I don't understand fully and I'm probably making some assumption
> that is false.
>
> re: 6) There are many advantages to using shared memory. For one, this
> database needs to be persistent. A simple re-start of the program would cause
> long periods of recovery as it read it's "last known good state" from some
> recover file or files. Ick. As it stands, re-starts are virtually  instantaneous.

OK.

> Shared memory also allows quite a bit of visibility into the data by
> utilities and "consumer" applications. While copying could (and does ) work I
> can't spare the cycles for it at 2 million (and increasing) transactions per
> second. I also tend to doubt that the fact that this memory is shared is
> causing me any real grief. I suspect that if I was using memory sections of
> this size "locally" my paging problems (or whatever this is) would still be
> evident.


Can you reduce this set of programs to its most basic?  ie remove
everything that actually processes the data allowing you to focus
just on the memory pools, then ping pong them as needed to
verify the sharing is not deadlocked?



> re: 7) I have 8 CPUs. I am going to experiment with affinitizing the
> producer and consumer to specific (possibly the same) cpu to see if this
> alleviates the problem.


<SNIP>
You mention above that CPU cycles are a potentrial problem, yet here
you would be ignoring 7 cpu's..


> re: 8) I do have similar benchmarking utilities/code. Another benefit of
> shared memory is that you can set markers into statistics areas to see where
> you are, what you are doing, how many transactions have been processed, etc.
> This very thing was what allowed me to see that I was not in the middle of an
> I/O (not an I/O issed by me) when I locked up.  On the contrary, I was in the
> middle of updating a transaction in memory - accessing a pointer. This is the
> puzzling (and frustrating) thing. To be sure I could very well have been
> faulting in (or out) large swaths of memory. Task manager showed that I was
> page faulting occasionally but when I froze the faulting ceased. It's very
> strange. Hopefully some of the kernal gurus may be able to tell me what could
> be going on.


You could get microsoft consulting in on this.  With XP source it seem simple
to find the exact cause of the deadlock.  There could be more than one..

Easiest way to fix a deadlock, is to not do as much locking..  Bigger/fewer locks,
smaller/faster locks Producer/Consumer patterns, Software Transactional Memory,
etc.


Have fun.

You could also try this:
http://developer.amd.com/cawin.jsp

Thanks! That looks VERY intersting!

"Robert" wrote:


> You could also try this:
> http://developer.amd.com/cawin.jsp 
> 
> 
> 

> Thanks! That looks VERY intersting!


I had thought that, too.  But the needed driver is 32 bit only..

So it does not run on my box.

Thanks again for all the help. 
I have definitely determined (using that fabulous AMD codeAnalyst tool) that 
I am in "memory manager" code and faulting in pages. I will continue to 
dig...however I have not observed the lock-up phenomena for the past few days 
(almost continuously running). I shrunk the size of the system file cache 
drastically and this seems to have really changed the dynamics of the system.

I intend to post to that windows drivers group you pointed me to. 

Again - many thanks!

I note you talk about 8 CPUs and 16GB of memory, with Windows XP.

Windows XP can't do that, you need Server Edition license.

Please check to make sure that all your resources are actually accessible 
through the OS.  I suspect everything is being crammed into 4 GB RAM and 2 
CPUs.

With regard to my previous message, the memory should not be a problem with 
XP 64-bit, as it looks like you have.  The CPUs still would be.

Please refer to: http://support.microsoft.com/kb/888732

> With regard to my previous message, the memory should not be a problem with XP 64-bit, as it looks like you have.  The 
> CPUs still would be.
>
> Please refer to: http://support.microsoft.com/kb/888732



Two quad core xeons would work.  You are limited to two sockets with xp 64.

AMD, at the moment, has no products in this area.