[ewg] ofa_1_5_kernel 20100706-0200 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git git_branch: ofed_kernel_1_5 Common build parameters: Passed: Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.24 Passed on i686 with linux-2.6.26 Passed on i686 with linux-2.6.22 Passed on i686 with linux-2.6.27 Passed on x86_64 with linux-2.6.16.60-0.54.5-smp Passed on x86_64 with linux-2.6.16.60-0.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-128.el5 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.18-194.el5 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.18-93.el5 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.22 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.24 Passed on x86_64 with linux-2.6.25 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.27.19-5-smp Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on x86_64 with linux-2.6.9-67.ELsmp Passed on x86_64 with linux-2.6.9-89.ELsmp Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.21.1 Passed on ia64 with linux-2.6.23 Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.26 Passed on ia64 with linux-2.6.24 Passed on ia64 with linux-2.6.25 Passed on ppc64 with linux-2.6.18 Passed on ppc64 with linux-2.6.19 Failed: ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] libibumad.so version bump in OFED 1.5.2
I recently discovered that 3rd party applications built for OFED 1.5 will not run on OFED 1.5.2rc2. The issue I found was that libibumad had changed from version 2 to version 3. Can you provide insight as to why this change was made? In reviewing the source code and change logs there do not seem to be any changes which would impact the application API nor application ABI. I diffed the code and the main change seems to be: diff -r --exclude CVS ./src/src/umad.c-orig ./src/src/umad.c 161a162,166 > if (sys_read_string(port_dir, SYS_PORT_LINK_LAYER, > port->link_layer, UMAD_CA_NAME_LEN) < 0) > /* assume IB by default */ > sprintf(port->link_layer, "IB"); > The above change might imply an update to an rpm dependency on ib-kernel versions, but should not result in a new library version. If the library version remained at 2, then applications built for OFED 1.5 would also run on OFED 1.5.2rc2 without recompile. The ChangeLog simply says: ** Version: libibumad-1.3.4 Sun Dec 13 19:39:11 2009 +0200 Sasha Khapyorsky 2ebf19e61bb887b226017c0ac5a7f30ea0cd9e3f * management: package versions bump Sun Dec 13 19:36:19 2009 +0200 Sasha Khapyorsky b7f0e58ada74b4da01a39a9c5fd2f5517d70d26a * management: update library versions Tue Nov 17 14:39:37 2009 -0800 Ira Weiny f25da9f189638c1772d7c3cc5e1942b8d1e8abf8 * libibmad: libibumad: Print warnings and errors to stderr not stdout Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 todd.rim...@qlogic.com www.QLogic.com ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] mvapich2 srpm uploaded
I've uploaded an update to mvapich2-1.5rc2 on the openfabrics server. It is located at ~perkinjo/ofed_1_5/mvapich2-1.5-0.2.20100705nightly.src.rpm. Thanks. On Tue, Jun 22, 2010 at 11:18 AM, Jonathan Perkins wrote: > Hi all: > Yesterday we released mvapich2-1.5rc2. I've uploaded the source rpm > to ~perkinjo/ofed_1_5/mvapich2-1.5-0.1.rc2.src.rpm on the openfabrics > server. This and future uploads can be identified by > ~perkinjo/ofed_1_5/latest.txt. > > -- > Jonathan Perkins > -- Jonathan Perkins ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v2] libibverbs: ibv_fork_init() and libhugetlbfs
On Sat, 03 Jul 2010 13:19:07 -0700 Roland Dreier wrote: > > When registering two memory regions A and B from within > > the same huge page, we will end up with one node in the tree which covers > the > > whole huge page after registering A. When the second MR is registered, a > node > > is created with the MR size rounded to the system page size (as there is no > > need to call madvise(), it is not noticed that MR B is part of a huge > page). > > > > Now if MR A is deregistered before MR B, I see that the tree containing > > mem_nodes is empty afterwards, which causes problems for the > deregistration of > > MR B, leaving the tree in a corrupted state with negative refcounts. This > also > > breaks later registrations of other memory regions within this huge page. > > Good thing I didn't get around to applying the patch yet ;) > > I haven't thought this through fully, but it seems that maybe we could > extend the madvise tracking tree to keep track of the page size used for > each node in the tree. Then for the registration of MR B above, we > would find the node for MR A covered MR B and we should be able to get > the ref counting right. We thought about this too, but in some special cases, we do not know the correct page size of a memory range. For example when getting a 16M chunk from a 16M huge page region which is also aligned to 16M, the first madvise() will work fine and the code will assume that the page size is 64K. If trying to register a 16M - 64K + 1 byte region, the first madvise() also works fine. Now if a second memory region which resides in the last 64K is registered, we end up with the same situation as above. As this issue was not present in version 2 of the code, but there we had a big performance penalty, I suggest the following: we could go back to version 2 and introduce a new RDMAV_HUGEPAGE_SAFE env variable to let the user decide between huge page support and better performance (the same approach we use for the COW protection itself). Would this be okay or do you see a problem with this? Regards, Alex ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] new libnes library for OFED 1.5.2 RC3
Vlad, Please pull in libnes-1.0.1-0.4.gd0446f8.tar.gz for RC3 build. I've updated latest.txt file in download/nes directory so it should be automatic. Please let me know if you run into any trouble with it. I didn't try to hack it this time and used topdir/dist/libnes.release number instead. Thanks, Chien ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v2] libibverbs: ibv_fork_init() and libhugetlbfs
> We thought about this too, but in some special cases, we do not know the > correct page size of a memory range. For example when getting a 16M chunk > from a 16M huge page region which is also aligned to 16M, the first madvise() > will work fine and the code will assume that the page size is 64K. I see ... yes, that does break my idea completely. OK, another half-baked idea: what if we pay attention to when madvise(DOFORK) fails as well as well madvise(DONTFORK) fails, and use that as a hit that we better check the page size? Perhaps this adds too much complexity ... in which case your idea: > As this issue was not present in version 2 of the code, but there we had > a big performance penalty, I suggest the following: we could go back to > version 2 and introduce a new RDMAV_HUGEPAGE_SAFE env variable to let the > user > decide between huge page support and better performance (the same approach we > use for the COW protection itself). seems like a reasonable alternative. Thanks, Roland -- Roland Dreier || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
