On Wed, May 14, 2008 at 06:11:22AM +0200, Nick Piggin wrote:
I assume by coherent domains, your are actually talking about system
images. Our memory coherence domain on the 3700 family is 512 processors
on 128 nodes. On the 4700 family, it is 16,384 processors on 4096 nodes.
We extend a "Read-Exclusive" mode beyond the coherence domain so any
processor is able to read any cacheline on the system. We also provide
uncached access for certain types of memory beyond the coherence domain.
For the other partitions, the exporting partition does not know what
virtual address the imported pages are mapped. The pages are frequently
mapped in a different order by the MPI library to help with MPI collective
operations.
For the exporting side to do those TLB flushes, we would need to replicate
all that importing information back to the exporting side.
Additionally, the hardware that does the TLB flushing is protected
by a spinlock on each system image. We would need to change that
simple spinlock into a type of hardware lock that would work (on 3700)
outside the processors coherence domain. The only way to do that is to
use uncached addresses with our Atomic Memory Operations which do the
cmpxchg at the memory controller. The uncached accesses are an order
of magnitude or more slower.
But it isn't that we are having a problem adapting to just the hardware.
One of the limiting factors is Linux on the other partition.
zap_page_range calls unmap_vmas which walks to vma->next. Are you saying
that can be walked without grabbing the mmap_sem at least readably?
I feel my understanding of list management and locking completely
shifting.
Are you suggesting the sending side would not need to sleep or the
receiving side? Assuming you meant the sender, it spins waiting for the
remote side to acknowledge the invalidate request? We place the data
into a previously agreed upon buffer and send an interrupt. At this
point, we would need to start spinning and waiting for completion.
Let's assume we never run out of buffer space.
The receiving side receives an interrupt. The interrupt currently wakes
an XPC thread to do the work of transfering and delivering the message
to XPMEM. The transfer of the data which XPC does uses the BTE engine
which takes up to 28 seconds to timeout (hardware timeout before raising
and error) and the BTE code automatically does a retry for certain
types of failure. We currently need to grab semaphores which _MAY_
be able to be reworked into other types of locks.
Thanks,
Robin
--
