Jeff Squyres wrote:
> Moving to devel; this question seems worthwhile to push out to the
> general development community.
> I've been coming across an increasing number of customers and other
> random OMPI users who use system(). So if there's zero impact on
> performance and it doesn't make the code [more] incredibly horrible
> [than it already is], I'm in favor of this change.
I will sound like a broken record, but this is the type of things that a
MPI implementation should not care about. At least not in the (common)
protocol layer. That's why the BTL-level abstraction is a bad one,
device-specific problems bubble up instead of staying hidden in
> On May 17, 2007, at 7:00 AM, Gleb Natapov wrote:
>> problem is that granularity of registration is HW page (4K), so last
What about huge pages ?
>> page of the buffer may contain also other application's data and user
>> may be unaware of this and be very surprised by SIGSEGV. If pipeline
How can a process get a segmentation fault by accessing a page mapped in
its own address space ?
>> so this situation will be avoided. It should have zero impact on
>> performance. What do you think? How common for MPI applications to
The only safe way to support fork() with pinned page is to force the
duplication of pages at fork time. It makes fork much more expensive,
but fork should not be in the critical path of HPC applications anyway.
Playing with registration cache is playing with fire.
My 2 cents.