Isaku Yamahata wrote:
> On Thu, May 24, 2007 at 12:28:46PM +0200, Jes Sorensen wrote:
> I don't agree here.
> I think fixing it with P=M requires much bigger efforts than
> paravirtualizing the files under sn/ directory.
> Looking around sn/ directory, I found that address conversion
> functions are centralized in linux/include/asm-ia64/sn/addr.h.
> It has only 295 lines. I don't think it's unrealistic to
> paravirtualize them.
Sorry, but there's more to it than that, there are other drivers and
there is the whole memory management layer too. We *must* support P=M,
it's just not an option. So lets try and fix the real problem and not
introduce this really broken assumption that we can treat all memory as
linear.
>>> In fact, Virtual Physical address model was introduced to
>>> resolve the grant table issue. And the ia64 default dma api and
>>> hp zx1 iommu are already paravirtulized.
>> There's much more to it than that. We need it for things like
>> alloc_pages_node() in the Linux kernel if we want any level of
>> performance.
>
> I'm talking about dma api paravirtualization, not NUMA.
> I believe that it's feasible to support NUMA without P=M.
In theory yes, but that means taking a hypercall for every single
memory allocation! How do you plan to handle CPU local and node
local memory pools if pages are just provided to the dom at random?
Without proper memory management, NUMA is not supported and the system
will never perform. Try treating a 64 node machine as a standard SMP
box and watch it behave like a 386.
>> I mean if we want to let individual dom's have direct access to a PCI
>> device. They will need to know where in the system it's physically
>> located.
>
> It is already supported.
No it isn't. Yes it probably works on Intel's super-simplified DIG
toys, it doesn't work on anything advanced.
Best regards,
Jes
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home