Hi Roland,
Roland Dreier wrote:
Stick in a separate library then?
I don't think we want the complexity in the kernel -- I personally would
argue against merging it upstream; and given that the userspace solution
is actually faster, it becomes pretty hard to justify.
Memory registration has al
On May 28, 2008, at 5:09 PM, Roland Dreier wrote:
I think Patrick's point is that it's not too much more expensive to
do the
syscall on Linux vs just doing the cache lookup, particularly in the
context of a long message. And it means that upper layer protocols
like
MPI don't have to deal w
> I think Patrick's point is that it's not too much more expensive to do the
> syscall on Linux vs just doing the cache lookup, particularly in the
> context of a long message. And it means that upper layer protocols like
> MPI don't have to deal with caches (and since MPI implementors hate
On Wed, 28 May 2008, Roland Dreier wrote:
>- gleb asks: don't we want to avoid the system call when possible?
>- patrick: a single syscall can be/is cheaper than a reg cache
> lookup in user space
This doesn't really make sense -- syscall + cache lookup in kernel is
"obviously" mor
>- gleb asks: don't we want to avoid the system call when possible?
>- patrick: a single syscall can be/is cheaper than a reg cache
> lookup in user space
This doesn't really make sense -- syscall + cache lookup in kernel is
"obviously" more expensive than cache lookup in userspace
brian: 1st point: propose remove opal/mca/memory/darwin (memory hooks
on OS X). Rationale:
- mvapi support is gone
- gm would be only user
- no one is supporting the code anymore (it ain't broke, but...)
--> patrick says: no problem. only myri osx customers have a special
mpich-m
