Hello there,
drivers/staging/rdma/hfi1/sdma.c:740:17: warning: logical ‘and’ of mutually
exclusive tests is always false [-Wlogical-op]
Source code is
if (count < 64 && count> 32768)
return SDMA_DESCQ_CNT;
Maybe better code
if (count < 64 || count> 32768)
return SDMA_D
On Fri, Sep 11, 2015 at 05:40:41PM -0400, Doug Ledford wrote:
> Then a simple mcast_expire_task that runs every 10 minutes or so and
> leaves any send-only groups that haven't had a packet timestamp update
> in more than some arbitrary amount of time would be a very simple
> addition to make.
That
On 09/11/2015 04:38 PM, Jason Gunthorpe wrote:
> On Fri, Sep 11, 2015 at 04:09:49PM -0400, Doug Ledford wrote:
>> On 09/11/2015 02:39 PM, Jason Gunthorpe wrote:
>>> On Thu, Sep 10, 2015 at 09:21:05PM -0400, Doug Ledford wrote:
During the recent rework of the mcast handling in ipoib, the join
>
On Fri, Sep 11, 2015 at 04:09:49PM -0400, Doug Ledford wrote:
> On 09/11/2015 02:39 PM, Jason Gunthorpe wrote:
> > On Thu, Sep 10, 2015 at 09:21:05PM -0400, Doug Ledford wrote:
> >> During the recent rework of the mcast handling in ipoib, the join
> >> task for regular and send-only joins were merg
On 09/11/2015 02:39 PM, Jason Gunthorpe wrote:
> On Thu, Sep 10, 2015 at 09:21:05PM -0400, Doug Ledford wrote:
>> During the recent rework of the mcast handling in ipoib, the join
>> task for regular and send-only joins were merged. In the old code,
>> the comments indicated that the ipoib driver
> > Trying to limit the number of QPs that an app can allocate,
> > therefore, just limits how much of the address space an app can use.
> > There's no clear link between QP limits and HW resource limits,
> > unless you assume a very specific underlying implementation.
>
> Isn't that the point tho
On Fri, Sep 11, 2015 at 07:22:56PM +, Hefty, Sean wrote:
> Trying to limit the number of QPs that an app can allocate,
> therefore, just limits how much of the address space an app can use.
> There's no clear link between QP limits and HW resource limits,
> unless you assume a very specific u
On 09/11/2015 02:21 PM, Jason Gunthorpe wrote:
> On Fri, Sep 11, 2015 at 09:40:25AM -0500, Christoph Lameter wrote:
>> On Thu, 10 Sep 2015, Doug Ledford wrote:
>>
>>> +* 1) ifdown/ifup
>>> +* 2) a regular mcast join/leave happens and we run
>>> +*ipoib_mcast_
Hello, Parav.
On Fri, Sep 11, 2015 at 10:09:48PM +0530, Parav Pandit wrote:
> > If you're planning on following what the existing memcg did in this
> > area, it's unlikely to go well. Would you mind sharing what you have
> > on mind in the long term? Where do you see this going?
>
> At least cur
> So, the existence of resource limitations is fine. That's what we
> deal with all the time. The problem usually with this sort of
> interfaces which expose implementation details to users directly is
> that it severely limits engineering manuevering space. You usually
> want your users to expr
Hello, Parav.
On Fri, Sep 11, 2015 at 10:17:42PM +0530, Parav Pandit wrote:
> IO controller and applications are mature in nature.
> When IO controller throttles the IO, applications are pretty mature
> where if IO takes longer to complete, there is possibly almost no way
> to cancel the system ca
On Thu, Sep 10, 2015 at 09:21:05PM -0400, Doug Ledford wrote:
> During the recent rework of the mcast handling in ipoib, the join
> task for regular and send-only joins were merged. In the old code,
> the comments indicated that the ipoib driver didn't send enough
> information to auto-create IB m
On Fri, Sep 11, 2015 at 09:40:25AM -0500, Christoph Lameter wrote:
> On Thu, 10 Sep 2015, Doug Ledford wrote:
>
> > +* 1) ifdown/ifup
> > +* 2) a regular mcast join/leave happens and we run
> > +*ipoib_mcast_restart_task
> > +* 3) a REREGISTER ev
The ehca driver is only supported on IBM machines with a custom EBus.
As they have opted to build their newer machines using more industry
standard technology and haven't really been pushing EBus capable
machines for a while, this driver can now safely be moved to the
staging area and scheduled for
> cpuset is a special case but think of cpu, memory or io controllers.
> Their resource distribution schemes are a lot more developed than
> what's proposed in this patchset and that's a necessity because nobody
> wants to cripple their machines for resource control.
IO controller and applications
On Fri, Sep 11, 2015 at 10:04 PM, Tejun Heo wrote:
> Hello, Parav.
>
> On Fri, Sep 11, 2015 at 09:56:31PM +0530, Parav Pandit wrote:
>> Resource run away by application can lead to (a) kernel and (b) other
>> applications left out with no resources situation.
>
> Yeap, that this controller would b
Hello, Parav.
On Fri, Sep 11, 2015 at 09:56:31PM +0530, Parav Pandit wrote:
> Resource run away by application can lead to (a) kernel and (b) other
> applications left out with no resources situation.
Yeap, that this controller would be able to prevent to a reasonable
extent.
> Both the problems
> If the resource isn't and the main goal is preventing runaway
> hogs, it'll be able to do that but is that the goal here? For this to
> be actually useful for performance contended cases, it'd need higher
> level abstractions.
>
Resource run away by application can lead to (a) kernel and (b) ot
On 09/11/2015 04:55 AM, Alexander Schmidt wrote:
> On Wed, 26 Aug 2015 06:46:48 -0700
> Christoph Hellwig wrote:
>
>> Hi Hoang-Nam, hi Christoph, hi Alexander,
>>
>> do you know what the current state of the eHCA driver and hardware is?
>>
>> The driver hasn't seen any targeted updats since 2010,
Hello, Parav.
On Fri, Sep 11, 2015 at 10:13:59AM +0530, Parav Pandit wrote:
> > My uneducated suspicion is that the abstraction is just not developed
> > enough. It should be possible to virtualize these resources through,
> > most likely, time-sharing to the level where userland simply says "I
>
Hello, Doug.
On Fri, Sep 11, 2015 at 12:24:33AM -0400, Doug Ledford wrote:
> > My uneducated suspicion is that the abstraction is just not developed
> > enough.
>
> The abstraction is 10+ years old. It has had plenty of time to ferment
> and something better for the specific use case has not eme
On Thu, 10 Sep 2015, Doug Ledford wrote:
> + * 1) ifdown/ifup
> + * 2) a regular mcast join/leave happens and we run
> + *ipoib_mcast_restart_task
> + * 3) a REREGISTER event comes in from the SM
> + * 4) any other event that mig
On 09/11/2015 03:14 AM, Or Gerlitz wrote:
> On 9/10/2015 7:53 PM, Doug Ledford wrote:
>>> >I don't see it in your kernel.org tree [1]
>> Because I didn't push it yet. I can push it now
>>
>> Push complete.
>>
>
> So we should keep chasing every commit you took and have humans look
> for it a
On Wed, 26 Aug 2015 06:46:48 -0700
Christoph Hellwig wrote:
> Hi Hoang-Nam, hi Christoph, hi Alexander,
>
> do you know what the current state of the eHCA driver and hardware is?
>
> The driver hasn't seen any targeted updats since 2010, so we wonder if
> it's still alive? It's one of the few
On 9/10/2015 7:53 PM, Doug Ledford wrote:
>I don't see it in your kernel.org tree [1]
Because I didn't push it yet. I can push it now
Push complete.
So we should keep chasing every commit you took and have humans look
for it among bunch of trees/branches, it's so tired-ing and annoyin
25 matches
Mail list logo
