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 || For corporate legal i

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 hate

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 userspace

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

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

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

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 e

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 quotes

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 pa

Re: [OMPI devel] Switching away from SVN?

> It's been loosely proposed that we switch away from SVN into a > different system. This probably warrants some discussion to a) figure > out if we want to move, and b) *if* we want to move, which system > should we move to? One has system been proposed: Mercurial -- several > OMPI

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 siz

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

> The main problem came from the fact that if we want to use our > modular approach on Windows (DLL loaded at runtime) we have to > compile in C++ mode. The C++ compiler consider the types int and long > as being different (even if they have the same number of bytes). No > implicit cast is all

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

> So, either we add the explicit cast from the beginning or I will have > to add it next time I compile on Windows ... I thought the problem with Windows was that long was always 32 bits (the same size as int) even on 64-bit platforms? - R.

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 implausib

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

> Because the target variable is an (int). If I were writing the code, I would leave the cast out. By assigning the value to an int variable, you get the same effect anyway, so the cast is redundant. And if you ever change the variable to a long, now you have to remember to delete the cast too.

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.

Re: [OMPI devel] MPI_Init() corrupts argc on Linux

> > Breakpoint 1, main (argc=1, argv=0xbf81fae4) at mpitest.c:6 > > 6 MPI_Init(&argc, &argv); > > (gdb) p argc > > $1 = 1 > > (gdb) n > > 7 MPI_Finalize(); > > (gdb) p argc > > Cannot access memory at address 0x0 > > (gdb) > > That's very odd. I don't see wh

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

Brian> It's even more annoying to be deluged with SPAM ;). We Brian> (the LAM developers) used to try to keep our mailing lists Brian> as open as possible. In the end, SPAM pushed the signal to Brian> noise ratio way too high and something had to be done. Brian> Requiring subs

[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 --- ompi/mca/btl/openib/btl_openib.c(revision 7507) +++ ompi/mca/btl/o