|
xen-devel
RE: [Xen-devel] RE: [Question] Why code differs in construct_dom0?
I do not know why kernel does this. But I do know that GART table in Intel
platform supports 64bit addresses. So in theory, allocating memory above 4G
should be OK.
Large memory requirement should be the result of architecture of onboard
graphic card. It has no own memory on card. Memory requirements must be
fulfilled by allocating from system memories.
Seems there is no good solution. Like what you said, a message asking for
setting dom0_mem may be better.
Shan Haitao
-----Original Message-----
From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
Sent: 2008年11月20日 21:13
To: 'Keir Fraser'; Shan, Haitao
Cc: 'xen-devel@xxxxxxxxxxxxxxxxxxx'
Subject: [Xen-devel] RE: [Question] Why code differs in construct_dom0?
>>> "Shan, Haitao" <haitao.shan@xxxxxxxxx> 20.11.08 13:52 >>>
>I think I may not have described the problem clearly. The system has 4G
>memory. From E820 table, there was near 3.5G usable ram below 4G
>and about 0.5G above 4G. Of all the ram, most of the memory was
>allocated to dom0, leaving only those for xen >itself such as xenheap
>and xen's reservations.
>We were using an onboard graphic card. When starting X, agpgart
allocated memory from kernel, then asked xen to exchange these
>pages to contiguous pages below 4G. Each time agpgart module did
>this job, some pages in kernel (which are actually >above 4G in
>physical memory) were replaced with contiguous pages below 4G.
>These kind of demands were rather high, about 256M in our platform.
>Finally, xen's reservation (128M) was not enough to fulfill this
>requirement.
>Why was the reservation exhausted? Because kernel kept asking for
>memory below 4G but only returning to xen memory above 4G. Then
>why is agpgart's allocation always in effect from above 4G? According
>to the code I pasted in my first mail, when pfn in >dom0 was small in
>number, mfn was large. The smaller the pfn was, the larger the
>corresponding mfn was. Apggart allocated memory with GFP_DMA32
>set, so the pfns allocated was likely to be small. Then the mfns were
>likely to be actually quite large (above 4G).
>
>Either increasing the reservation (like 384M) or changing the initial p2m
>mapping in dom0 can solve the problem, and our tests verified this
>judgment. We do not know which solution is better. That's why we are
>seeking your kindly help. I am not sure if I have explained clearly
>enough so far. So any questions on the problem itself, Keir?
Neither of the suggested solutions seems correct to me - both would only
defer the point where the problem occurs. The question really is why
agpgart needs so much memory below 4G. And if that really isn't a bug
somewhere else, then requiring a sufficiently large negative value to
be passed with dom0_mem= would seem to be the only option on this
system (but not as a global default).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home