>
> Hi James:
>
> Unfortunately, We still hit the blue screen on the stress test.
> (Start total 24 HVMS on a single 16core, 24G host,
> each HVM owns 2G Memory, start with memory=512M,
> and inside two eating memory processes, each of which will each 1G
> memory)
>
> As I go though the code, I noticed that all memory allocation relates
to
> "ExAllocatePoolWithTag(NonPagedPool,...)", which is from NonePaged
Pool,
> As I know, the NonePagePool memory is the memory could not be paged
out,
> and that is limited, and for the blue screen VMS, I also found the
free
> memory is quite low, only about hundreds KB left.
>
> So, when memory overcommit, some of the VM will not got enough memory,
> and if most of its Memory is occupied by eating memory process, then
> ExAllocatePoolWithTag
> will fail, thus caused "NO_PAGES_AVALIABLE" blue screen. Is this
possible?
>
> Meanwhile, I will have your PVdriver tested to see if blue exists,
Yes you are correct - NonPagedPool memory that will always be available.
Most of my driver code is required at some point to run at
DISPATCH_LEVEL (an IRQ priority level - not sure if you are familiar
with the concept) and at DISPATCH_LEVEL any attempt to access memory
that is paged out to disk will result in a blue screen.
There are overheads with adding more memory to the system. Windows has
to keep track of every page of memory so the more memory you have the
more memory windows has to keep track of, and this in turn uses up more
memory. If you had a system with maxmem=32768 and memory=256 or
something in that order of numbers then maybe Windows needs most of that
256MB to keep track of the 32GB of memory and doesn't have enough left
for itself.
In your original email you said you were using maxmem=2048 and
memory=512 so maybe that isn't the problem.
Looking at the bug check, parameter 1 and 2 are both 0x0002A8FB (about
714MB). This means that there is 714MB of 'dirty' pages to be written to
the pagefile. I think this might happen if you tried to allocate too
much memory too fast and Windows couldn't write it out to disk fast
enough (it could also happen if xenvbd had hung or something). Maybe a
delay is needed when allocating memory, or else some sort of feedback
into the ballooning down code.
I'll post on ntdev for advice.
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home