Re: [OMPI devel] Fwd: + ummunotify-userspace-support-for-mmu-notifications-v2.patch added to -mm tree

> Woo hoo! It looks like ummunotify went into the -mm kernel tree yesterday. Yeah, I was wondering what Andrew's plans are for this. Nothing has changed so I'm not sure whether it gets merged all the way to Linus this time either. - R. -- Roland Dreier <rola...@cisco.com> || For

Re: [OMPI devel] -display-map and mpi_spawn

> thanks, applied oops, replied to the wrong message ;)

Re: [OMPI devel] -display-map and mpi_spawn

thanks, applied

Re: [OMPI devel] ibcm private header file

> So I think using byteorder.h is not a good idea (note the warning). > How about just having two #defines, picking the Right one based on > WORDS_BIGENDIAN? On Linux, the public header might have what you need. For that matter has htonll() defined. - R.

Re: [OMPI devel] RFC: Linuxes shipping libibverbs

> Is it possible that /sys/class/infiniband directory exist and it is > empty ? In which cases ? Do "modprobe ib_core" on a system with no hardware drivers loaded (or no RDMA hardware installed)

Re: [OMPI devel] Notes from mem hooks call today

> 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

Re: [OMPI devel] Notes from mem hooks call today

>- 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

Re: [OMPI devel] RFC: Linuxes shipping libibverbs

> Either that or udev in not configured properly. Debian has a correct udev configuration, modulo http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449081 > ib_core/mthca/mlx4 should be loaded automatically by hotplug if HW is > present. No need for any additional configuration. Yes

Re: [OMPI devel] RFC: Linuxes shipping libibverbs

> OFED is one distribution of the OpenFabrics software. It can be > bundled up and packaged differently, too. I suspect that Debian does > not include OFED directly, because OFED is pretty heavily dependent > upon RPM. So the OpenFabrics kernel bits must be there somewhere >

Re: [OMPI devel] OMPI Mercurial read-only mirror

> > > Can I make a /tmp branch from the hg read-only branch that is not tied > > > to the svn /tmp branches. > > Why do you want to do that? > > > > Mercurial is a fully distributed system, so you could just start > > committing to one of your local copies of the repository, and I can't

Re: [OMPI devel] OMPI Mercurial read-only mirror

> Can I make a /tmp branch from the hg read-only branch that is not tied > to the svn /tmp branches. Why do you want to do that? Mercurial is a fully distributed system, so you could just start committing to one of your local copies of the repository, and I can't see anything missing that a

Re: [OMPI devel] Affect of compression on modex and launch messages

> Based on some discussion on this list, I integrated a zlib-based compression > ability into ORTE. Since the launch message sent to the orteds and the modex > between the application procs are the only places where messages of any size > are sent, I only implemented compression for those two

Re: [OMPI devel] Switching away from SVN?

LWN.net has an interesting article about how Emacs chose a new version control system: They were back in the CVS stone ages, but their main contenders were the same big three of distributed VCSs: git, hg and bzr. The article pulls out a couple of very good

Re: [OMPI devel] Switching away from SVN?

has some interesting info about svn->git conversions (and svn vs. next-gen distibuted systems in general). Also, out of curiousity I tried doing git-svn clone --stdlayout http://svn.open-mpi.org/svn/ompi/ and it seemed to work fine (git-svn is

Re: [OMPI devel] replace 'atoi' with 'strtol'

> I see... so the right way to right this is really: err... "right way to WRITE this" - R.

Re: [OMPI devel] replace 'atoi' with 'strtol'

> How about (u)int32_t? When I was an Ada programmer, subtypes with the > approriate range were always encouraged (i.e.: define the semantical > range and let the compiler/runtime library warn you on range > violations (the well-known "CONSTRAINT_ERROR")) It's OK to use a type with a fixed

Re: [OMPI devel] replace 'atoi' with 'strtol'

> I.e., it returns a long. Although some compilers might do the right > thing, conversions should be explicitly shown. Isn't the behavior guaranteed by the C standard? And I can't even imagine a way for a compiler to get intvar = strtol(foo); wrong, and it seems even more

Re: [OMPI devel] replace 'atoi' with 'strtol'

> With the (int) cast, I'm ok with it now. :-) What's the point of the cast to int? - R.

[O-MPI devel] [PATCH] Update Open MPI for new libibverbs API

[It's somewhat annoying to have to subscribe to de...@open-mpi.org just to be able to send patches, but oh well...] This patch updates Open MPI for the new ibv_create_cq() API. Signed-off-by: Roland Dreier <rola...@cisco.com> --- ompi/mca/btl/openib/btl_openib.c(revision 7507) +++ om