On Fri, Aug 15, 2014 at 3:08 PM, Wendy Cheng <s.wendy.ch...@gmail.com> wrote:
> On Tue, Aug 12, 2014 at 4:38 PM, Doug Ledford <dledf...@redhat.com> wrote:
[snip]
>>
>> Doug Ledford (8):
>>   IPoIB: Consolidate rtnl_lock tasks in workqueue
>>   IPoIB: Make the carrier_on_task race aware
>>   IPoIB: fix MCAST_FLAG_BUSY usage
>>   IPoIB: fix mcast_dev_flush/mcast_restart_task race
>>   IPoIB: change init sequence ordering
>>   IPoIB: Use dedicated workqueues per interface
>>   IPoIB: Make ipoib_mcast_stop_thread flush the workqueue
>>   IPoIB: No longer use flush as a parameter
>>
>
> IPOIB is recently added as a technology preview for Intel Xeon Phi
> (currently a PCIe card) that runs embedded Linux (named MPSS) with
> Infiniband software stacks supported via emulation drivers. One early
> feedback from users with large cluster nodes is IPOIB's power
> consumption. The root cause of the reported issue is more to do with
> how MPSS handles its DMA buffers (vs. how Linux IB stacks work) - so
> submitting the fix to upstream is not planned at this moment (unless
> folks are interested in the changes).
>
> However, since this patch set happens to be in the heart of the
> reported power issue, we would like to take a closer look to avoid
> MPSS code base deviating too much from future upstream kernel(s).
> Question, comment, and/or ack will follow sometime next week.
>

I've reviewed the patch set - the first half of the patches look good.
Patch #5,#6,#7,#8 are fine if we go for one WQ per device - will let
others do the final call.

On our system (OFED 1.5.4 based), similar deadlocks were also observed
while the power management issues were worked on. Restricted by other
issues that were specific to our platform, I took the advantage of
single IPOIB workqueue by queuing the if-up(s) and/or if-down(s) to
the work queue if one already in progress. It serialized the logic by
default. However, I would not mind one WQ per device approach and will
re-make the changes when this patch set is picked up by mainline
kernel.

-- Wendy
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to