RE: [Xen-merge] arch/i386/mach-xen/mm/highmem.c indentical

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

 > > I've actually got a patch sitting in my tree that touches 
> this file, 
> > and is important for making kmap (>900MB) work well on Xen. 
> I haven't 
> > checked it in because I don't totally like the approach of 
> introducing 
> > "kset_pte_at", though we clearly need something checked in because 
> > it's a huge win on some benchmarks.
> 
> Also, highmem aren't identical, there was a preceding patch 
> which did that.  The subarch is functional, but does have 
> redundant bits in it.
> I've since removed highmem.  I'd avoid kset_* since it'll 
> look like kset handling (as in kobject and sysfs).  I didn't 
> look closely yet, but what cases would you not want this 
> redifintion of set_pte_at?  I

We have three mechanisms that we can use to update pagetables in Xen
that have different performance tradeoffs:

 1. writeable pagetables (implemented by set_pte). This is best used for
bulk updates of pagetables e.g. fork, zap etc.

 2. queue_l1_update. This is best used for singleton updates. The
'queue' in the name is a bit of a misnomer as we now no longer ever
queue things because: (a) working out where to put the flushes to avoid
read-after-write hazards on pending updates is hard, and  (b) its
impossible to make SMP guests work with good perofrmance. [This is one
of the bigest 'holes' in the VMI proposal]

 2. update_va_mapping. This can be used when you know the virtual
address that the pte is responsible for, and you know that it is in your
current address space. Xen uses the linear pagetable to avoid having to
dynamicly map the domain memory. It's very useful for performance
critical things like the demand fault path and kmap (highmem).
[for kmap you may need to fall-back to a queue_l1_update in case the
page is not mapped into the PGD]


Best,
Ian

_______________________________________________
Xen-merge mailing list
Xen-merge@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-merge