From vlad at lists.openfabrics.org Thu Oct 1 03:23:05 2009 From: vlad at lists.openfabrics.org (Vladimir Sokolovsky Mellanox) Date: Thu, 1 Oct 2009 03:23:05 -0700 (PDT) Subject: [ofa-general] ofa_1_5_kernel 20091001-0200 daily build status Message-ID: <20091001102305.C41BEE62036@openfabrics.org> 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.19 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.21.1 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.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.18-128.el5 Passed on x86_64 with linux-2.6.18-93.el5 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.20 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.22 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.9-67.ELsmp Passed on x86_64 with linux-2.6.9-78.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.24 Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.26 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: From vlad at lists.openfabrics.org Fri Oct 2 03:14:01 2009 From: vlad at lists.openfabrics.org (Vladimir Sokolovsky Mellanox) Date: Fri, 2 Oct 2009 03:14:01 -0700 (PDT) Subject: [ofa-general] ofa_1_5_kernel 20091002-0200 daily build status Message-ID: <20091002101401.5C93AE620C4@openfabrics.org> 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.26 Passed on i686 with linux-2.6.24 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.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.18-128.el5 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.19 Passed on x86_64 with linux-2.6.21.1 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.22 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on x86_64 with linux-2.6.9-67.ELsmp Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.21.1 Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.23 Passed on ia64 with linux-2.6.24 Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.26 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: From rdreier at cisco.com Fri Oct 2 09:32:00 2009 From: rdreier at cisco.com (Roland Dreier) Date: Fri, 02 Oct 2009 09:32:00 -0700 Subject: [ofa-general] Re: [GIT PULL] please pull ummunotify In-Reply-To: <20090930094456.GD24621@elte.hu> (Ingo Molnar's message of "Wed, 30 Sep 2009 11:44:56 +0200") References: <1253187028.8439.2.camel@twins> <1253198976.14935.27.camel@laptop> <20090929171332.GD14405@elf.ucw.cz> <20090930094456.GD24621@elte.hu> Message-ID: > Per tracepoint filtering is possible via the perf event patches Li Zefan > has posted to lkml recently, under this subject: > > [PATCH 0/6] perf trace: Add filter support > > They are still being worked on but it's very clear that flexible > in-kernel filtering support will be a natural part of the perf event > design in the very near future, so if that alone is your reason not to > use it it would be better if you helped us complete/test the filter > support and use that, instead of a parallel framework. > > Or if that's not desirable or not possible, or if there's any other > technical roadblock, i'd like to know the particulars of that. So I looked a little deeper into this, and I don't think (even with the filtering extensions) that perf events are directly applicable to this problem. The first issue is that, assuming I'm understanding the comment in perf_event.c: /* * Raw tracepoint data is a severe data leak, only allow root to * have these. */ currently tracepoints can only be used by privileged processes. A key feature of ummunotify is that ordinary unprivileged processes can use it. So would it be acceptable to add something like PERF_TYPE_MMU_NOTIFIER as a way of letting unprivileged userspace get access to just MMU events for their own process? Clearly this touches core infrastructure and is not as simple as just adding two tracepoints. Then, assuming we have some way to create an "MMU notifier" perf event, we need a way for userspace to specify which address ranges it would like events for (I don't think the string filter expression used by existing trace filtering works, because if userspace is looking at a few hundred regions, then the size of the filtering expression explodes, and adding or removing a single range becomes a pain). So I guess a new ioctl() to add/remove ranges for MMU_NOTIFIER perf events? I think filtering is needed, because otherwise events for ranges that are not of interest are just a waste of resources to generate and process, and make losing good events because of overflow much more likely. We still have the problem of lost events if the mmap buffer overflows, but userspace should be able to size the buffer so that such events are rare I guess. In the end this seems to just take the ummunotify code I have, and make it be a new type of perf counter instead of a character special device. I'd actually be OK with that, since having an oddball new char dev interface is not particularly nice. But on the other hand just multiplexing a new type of thing under perf events is not all that much better. What do you think? Thanks, Roland From vlad at lists.openfabrics.org Sat Oct 3 03:08:18 2009 From: vlad at lists.openfabrics.org (Vladimir Sokolovsky Mellanox) Date: Sat, 3 Oct 2009 03:08:18 -0700 (PDT) Subject: [ofa-general] ofa_1_5_kernel 20091003-0200 daily build status Message-ID: <20091003100818.ECC43E620C9@openfabrics.org> 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.19 Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.18 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.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.18-128.el5 Passed on x86_64 with linux-2.6.18-93.el5 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.20 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.22 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on x86_64 with linux-2.6.9-67.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.24 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.25 Passed on ppc64 with linux-2.6.18 Passed on ppc64 with linux-2.6.19 Failed: From vlad at lists.openfabrics.org Sun Oct 4 03:08:40 2009 From: vlad at lists.openfabrics.org (Vladimir Sokolovsky Mellanox) Date: Sun, 4 Oct 2009 03:08:40 -0700 (PDT) Subject: [ofa-general] ofa_1_5_kernel 20091004-0200 daily build status Message-ID: <20091004100840.501CCE61F8F@openfabrics.org> 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.21.1 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.26 Passed on i686 with linux-2.6.24 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.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.18-128.el5 Passed on x86_64 with linux-2.6.18-93.el5 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.24 Passed on x86_64 with linux-2.6.22 Passed on x86_64 with linux-2.6.25 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on x86_64 with linux-2.6.9-67.ELsmp Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.21.1 Passed on ia64 with linux-2.6.23 Passed on ia64 with linux-2.6.24 Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.26 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: From vlad at lists.openfabrics.org Mon Oct 5 03:06:33 2009 From: vlad at lists.openfabrics.org (Vladimir Sokolovsky Mellanox) Date: Mon, 5 Oct 2009 03:06:33 -0700 (PDT) Subject: [ofa-general] ofa_1_5_kernel 20091005-0200 daily build status Message-ID: <20091005100633.B785DE61C38@openfabrics.org> 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.19 Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.26 Passed on i686 with linux-2.6.24 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.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.18-128.el5 Passed on x86_64 with linux-2.6.18-93.el5 Passed on x86_64 with linux-2.6.19 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.24 Passed on x86_64 with linux-2.6.22 Passed on x86_64 with linux-2.6.25 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on x86_64 with linux-2.6.9-67.ELsmp Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.21.1 Passed on ia64 with linux-2.6.23 Passed on ia64 with linux-2.6.24 Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.26 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: From rdreier at cisco.com Wed Oct 7 15:34:47 2009 From: rdreier at cisco.com (Roland Dreier) Date: Wed, 07 Oct 2009 15:34:47 -0700 Subject: [ofa-general] Re: [GIT PULL] please pull ummunotify In-Reply-To: (Roland Dreier's message of "Fri, 02 Oct 2009 09:32:00 -0700") References: <1253187028.8439.2.camel@twins> <1253198976.14935.27.camel@laptop> <20090929171332.GD14405@elf.ucw.cz> <20090930094456.GD24621@elte.hu> Message-ID: > So I looked a little deeper into this, and I don't think (even with the > filtering extensions) that perf events are directly applicable to this > problem. The first issue is that, assuming I'm understanding the > comment in perf_event.c: > > /* > * Raw tracepoint data is a severe data leak, only allow root to > * have these. > */ > > currently tracepoints can only be used by privileged processes. A key > feature of ummunotify is that ordinary unprivileged processes can use it. > > So would it be acceptable to add something like PERF_TYPE_MMU_NOTIFIER > as a way of letting unprivileged userspace get access to just MMU events > for their own process? Clearly this touches core infrastructure and is > not as simple as just adding two tracepoints. > > Then, assuming we have some way to create an "MMU notifier" perf event, > we need a way for userspace to specify which address ranges it would > like events for (I don't think the string filter expression used by > existing trace filtering works, because if userspace is looking at a few > hundred regions, then the size of the filtering expression explodes, and > adding or removing a single range becomes a pain). So I guess a new > ioctl() to add/remove ranges for MMU_NOTIFIER perf events? > > I think filtering is needed, because otherwise events for ranges that > are not of interest are just a waste of resources to generate and > process, and make losing good events because of overflow much more > likely. > > We still have the problem of lost events if the mmap buffer overflows, > but userspace should be able to size the buffer so that such events are > rare I guess. > > In the end this seems to just take the ummunotify code I have, and make > it be a new type of perf counter instead of a character special device. > I'd actually be OK with that, since having an oddball new char dev > interface is not particularly nice. But on the other hand just > multiplexing a new type of thing under perf events is not all that much > better. What do you think? Ingo/Peter/ -- can you comment on this plan of creating PERF_TYPE_MMU_NOTIFIER for perf events to implement ummunotify? To me it looks like a wash -- the main difference is how userspace gets the magic ummunotify file descriptor, either by open("/dev/ummunotify") or by perf_event_open(...PERF_TYPE_MMU_NOTIFIER...), but pretty much everything else stays pretty much the same in terms of how much kernel code is involved. We do reuse the perf events mmap buffer code but I think that ends up being more complicated than returning events via read(). Anyway, before I spend the time converting over to the new infrastructure and causing the MPI guys to churn their code, I'd like to make sure that this is what you guys have in mind. (By the way, after thinking about this more, I really do think that filtering events by address range is a must-have -- with filtering, userspace can map sufficient buffer space to avoid losing events for a given number of regions; without filtering, events might get lost just because of invalidate events for ranges userspace didn't even care about) Thanks, Roland From rdreier at cisco.com Wed Oct 7 15:45:16 2009 From: rdreier at cisco.com (Roland Dreier) Date: Wed, 07 Oct 2009 15:45:16 -0700 Subject: [ofa-general] Re: [ewg] [PATCH] mlx4: remove limitation on LSO header size In-Reply-To: <20090930090701.GA2385@mtls03> (Eli Cohen's message of "Wed, 30 Sep 2009 11:07:01 +0200") References: <20090930090701.GA2385@mtls03> Message-ID: > + *blh = unlikely(halign > 64) ? 1 : 0; This idiom of "(boolean condition) ? 1 : 0" looks odd to me... doesn't (halign > 64) already evaluate to 1 or 0 anyway? Does the unlikely() actually affect code generation here? With that said, see below... > + int blh = 0; I assume this initialization is to avoid a compiler warning. But the code is actually correct without initializing blh -- so I think that we save a tiny bit of code by doing uninitialized_var() instead? > + (blh ? cpu_to_be32(1 << 6) : 0); ...given that the only use of blh is as a flag to decide what constant to use here, does it generate better code to make blh be __be32 and set the value directly in build_lso_seg, ie do: *blh = unlikely(halign > 64) ? cpu_to_be32(1 << 6) : 0; and then use blh without ?: in mlx4_ib_post_send... - R. From rdreier at cisco.com Mon Oct 12 10:03:03 2009 From: rdreier at cisco.com (Roland Dreier) Date: Mon, 12 Oct 2009 10:03:03 -0700 Subject: [ofa-general] Re: [ewg] [PATCH] mlx4: remove limitation on LSO header size In-Reply-To: <20091011100015.GB4929@mtls03> (Eli Cohen's message of "Sun, 11 Oct 2009 12:00:15 +0200") References: <20090930090701.GA2385@mtls03> <20091011100015.GB4929@mtls03> Message-ID: > > > + *blh = unlikely(halign > 64) ? 1 : 0; > > This idiom of "(boolean condition) ? 1 : 0" looks odd to me... doesn't > > (halign > 64) already evaluate to 1 or 0 anyway? Does the unlikely() > > actually affect code generation here? > True, (halign > 64) is the same and is cleaner. As for the unlikely() > -- well it's already been there and besides, we're never sure if it > will improve anything so the same question could be asked for other > places in the code. I was just wondering in this case where you are just assigning the boolean value of the expression to a variable how unlikely affects things. I can understand for conditional jumps how the compiler can choose to make the likely case more efficient, but when there are no jumps then I was just curious how the hint could help. > > I assume this initialization is to avoid a compiler warning. But the > > code is actually correct without initializing blh -- so I think that we > > save a tiny bit of code by doing uninitialized_var() instead? > We must initialize blh since it is used for any send request and not > just LSO opcodes. So then this patch was buggy because blh was not reinitialized as we loop through multiple work requests? eg an LSO request followed by a non-LSO request? Anyway I'll look over the newer patch.