[MPICH] Availability of the Driller library

[Jean-Marc Saffroy]

Hi Darius,

Thanks for your feedback!

On Mon, 24 Sep 2007, Darius Buntinas wrote:

> The readme says that it does the switch atomically.  How do you make the 
> copy from memory to the file atomic? You could have a situation when one 
> thread is modifying memory while the other thread is performing the 
> copy.  Do you handle this situation?

First, multiple threads are not handled at all in this code: the whole 
thing is strange enough that I wanted to try it with single threaded 
processes first, and this can already be useful. It may be possible to 
handle multiple threads, but this will require a bit more thinking.

Signals are also an interesting problem, but probably easier to deal with 
(I suspect it's mostly a matter of blocking all signals in some parts of 
the Driller code).

I guess "atomic" was not the word I should have used here. What I meant to 
say is that before and after the call to mmap that replaces an existing 
memory region [*], the process can access this memory. Which is not the 
whole truth, since a segment should not be modified after it has been 
copied to a file and before it has been remapped; this means that read and 
execute access can continue, but this is not as useful as I expected (I 
disabled remapping of executable regions when I saw that it confused 
oprofile, although it works fine).

[*] Note that this copy only occurs on memory segments that exist when 
driller_init() is called; private anonymous segments requested after that 
(typically by malloc) are immediately created inside memory-mapped files.

> Is there a way to split a vma and share only part of it?  That would be 
> interesting as well.

Hmmm that would be possible, but the cost of sharing part or all of a 
given memory region is roughly the same, so why would you want to do this?


Cheers,

-- 
saffroy at gmail.com