[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: blue screen in windows balloon driver
> > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |